[cfe-dev] RFC: Clang and libstdc++ versions, string.h and cstring conflicts, and glibc patches.

[Brooks Moses]

[Replying to both replies in one email]

On Thu, Aug 29, 2013 at 4:56 PM, "C. Bergström"
<cbergstrom at pathscale.com> wrote:
> Anyone using a clang based front-end will probably be forced to define
> __clang__. This isn't common, but there's at least 1 and possibly 2 or more
> non-llvm based compilers doing this that I'm aware of. In the cases that I'm
> aware of - those modified versions of clang are post-may-2012 though.

Thanks for the clarification!

> (PathScale compiler is recent modified clang + recent libc++ || STDCXX and
> while we could in theory play nice with the system libstdc++, we don't ever
> use it beyond some internal testing.)

Ok.  As full disclosure, this may break STDCXX -- but if it does, the
fix is straightforward.  Glibc's string.h defines a
__CORRECT_ISO_CPP_STRING_H_PROTO macro when it provides the correct
C++ prototypes, and STDCXX can check that to turn them off.  As a
bonus, this will also fix STDCXX's equivalent of libc++ bug 7983 for
compilation with GCC 4.4 and later.

> please no non-standard or standard breaking things (I prefer either option 1
> or 2 below)

I'm not sure I understand your argument that the __cplusplus proposal
is either non-standard or standard-breaking.  Would you mind
explaining that reasoning?

The value of 199701L for __cplusplus is of course completely standard.
 What checking for that would mean is that glibc's string.h would
export the correct C++-standard function definitions when it's
compiled with any compiler that has the correct C++-standard value for
__cplusplus -- which I'd say is precisely standard-conforming
behavior.  (This then implies that it's relying on that compiler to
use a library with a cstring header that correctly deals with a
string.h that follows the standard.)

The old __cplusplus value of 1 also happens to have meaning in the C++
standard; the standard states that non-conforming implementations
should use values with 5 or fewer decimal digits.  It seems to me that
it's reasonable for glibc to maintain the current (non-standard)
string.h definitions in that case.

> 2) go with a __clang__ version check

What version check would you recommend, if you would recommend
something other than just checking for whether __clang__ is defined?


On Thu, Aug 29, 2013 at 5:16 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> The "right" solution is really something like "#if _LIBCPP_VERSION ||
> __GLIBCXX__ > 20070719" (replace 20070719 with the right date), but I don't
> know if there's any reliable way to get the right definition of __GLIBCXX__.
> (You should be able to get the definition of _LIBCPP_VERSION without causing
> circular dependencies by including ciso646.)

Unfortunately, it's even messier than that -- there is no right date,
because the __GLIBCXX__ values are purely release dates, and (for
example) GCC 4.3.6 was released after 4.6.0.  We'd need to check for
about a half-dozen different specific values in the overlap.  (Also,
including ciso646 doesn't define __GLIBCXX__ in libstdc++, more's the
pity.)


Thanks for the feedback!
- Brooks