TIME_UTC is a macro in C11

[pmachata@…]

Excerpt from the C11 standard draft that I have at hand:

7.27 Date and time <time.h>
The macros defined are [...] TIME_UTC which expands to an integer constant greater than 0 that designates the UTC time base.

glibc implements this in development version, though the latest release (2.15) doesn't yet include this code. The Linux distribution Fedora rawhide (what is to become Fedora 18) now includes this code as well.

This collides with the following code in boost/thread/xtime.hpp, which thus becomes invalid, as it includes <ctime> via <boost/thread/thread_time.hpp>.

enum xtime_clock_types
{
    TIME_UTC=1
[...]

Unfortunately, on Linux, this is a problem in any C++ code. g++ implicitly defines _GNU_SOURCE, which in turn causes _ISOC11_SOURCE to be defined, regardless of what C++ standard is actually used. But regardless of this gcc feature, the boost interfaces are broken if I want to use C11 interfaces from C++ code.

I couldn't find any recent documentation on this interface. It doesn't seem to be used much, and some old documentation (1.34) states that it will be obsoleted at some point. What would be used instead?

Just dropping that enum would probably work in case of Fedora in particular, and that's what I'm going to do for boost package in Fedora. The type itself is never used. Users of the sole enum value would have to be changed from boost::TIME_UTC to mere TIME_UTC (taken from glibc), as the two happen to have the same value. That would be about it. But that's clearly not acceptable as an upstream solution.

[pmachata@…]

Note, it would be possible to arrange for TIME_UTC value to be defined before <ctime> is (transitively) included, but that wouldn't be very useful: each client would have to undef TIME_UTC anyway, otherwise boost::TIME_UTC would be expanded and would become an invalid code.

[viboes]

Change done: replace TIME_UTC by TIME_UTC_.

Committed in trunk at revision 78802.

[viboes]

Merged to release branch.

[Denis Arnaud]

Just for the sake of having a link on the revision [78802], fixing issue #6940.

[smr@…]

Despite the claim that this has been merged to release, Boost 1.53 still contains this bug.

[viboes]

Please see ​https://svn.boost.org/trac/boost/changeset/78973#file3

[Will Karter]

Source

[Will Karter]

Source