[patch] Define __CORRECT_ISO_CPP_STRING_H_PROTO correctly for Clang

[Brooks Moses]

On Thu, Aug 29, 2013 at 5:18 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> What's the logic behind the GCC version check in the first place?  Is it
> about compiler (language) features, or about corresponding support in the
> standard C++ library?  If the former, do you need a Clang version check?
> If the latter, do you need a check on what version of libstdc++ or libc++
> might be used with Clang?

This appears to be about corresponding support in libstdc++.  The
original patch was actually only posted to gcc-patches@, here [1]:
 http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01457.html
Prior to the patch, libstdc++'s cstring provided the C++ declarations
of the string.h functions.  After the patch, the libstdc++ cstring
only provides the C++ string.h declarations if these macros are not
defined, so as to avoid conflicting with glibc's string.h
declarations.

In libc++, the corresponding declarations are guarded by a simple
"!defined(__GLIBC__)" check, and have been since the very early days
of the project; thus this should be safe for that as well [2].

In principle, the correct solution might be replacing the GCC version
check with a check on __GLIBCXX__ and _LIBCPP_VERSION.  However,
__GLIBCXX__ is not monotonic with the GCC version[3] so this would be
a very messy check, and there's the issue of getting the __GLIBCXX__
value in a way that is guaranteed not to introduce circular header
dependencies in libstdc++ or any other C++ library.  So unfortunately
I don't think that's workable in practice.

I brought this up with the Clang development mailing list, and the
answer I got there was that "In practice, any of the solutions is
probably fine: glibc gets upgraded along with the system, which
implies a newer gcc, which implies clang will find a newer libstdc++"
[4].

Thus, I'd like to go with Andrew Pinski's idea of using a
"__cplusplus>=199711L" check, and use the legacy behavior (check for
GCC of 4.4 or later) otherwise.  As I explain in the code comment,
this basically assumes that C++ compilers that claim to fully support
C++98 are using a standard-conforming C++ standard library, which
seems pretty reasonable.  Clang has been providing an appropriate
value of __cplusplus since May of last year.

The revised patch is attached.  I've tested it by compiling a file
that includes the headers and checks the macro values, with GCC 4.6,
GCC 4.8, and a recent build of Clang, and I confirmed that the macros
are defined as expected in all cases.  I've attached the test program
as well.

Is this version ok to commit?

Thanks,
- Brooks


[1] For archival purposes: There was also a bugfix on it sent to libc-hacker@:
http://sourceware.org/ml/libc-hacker/2009-01/msg00013.html

[2]: Discussion of the libc++ cstring prototypes here:
http://llvm.org/svn/llvm-project/libcxx/trunk/include/cstring
http://llvm.org/bugs/show_bug.cgi?id=7983

[3]: See list of __GLIBCXX__ values over the years:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

[4] This quote is from email from Eli Friedman:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031657.html

[5] Clang generally followed GCC practice for __cplusplus values;
discussion and patch here:
http://clang-developers.42468.n3.nabble.com/Value-of-cplusplus-in-GNU-modes-td3957527.html
http://llvm.org/viewvc/llvm-project?revision=156113&view=revision
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2013-09-09_string-cpp-prototypes.diff
Type: application/octet-stream
Size: 1513 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20130909/73b186a4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.cc
Type: application/octet-stream
Size: 365 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20130909/73b186a4/attachment-0001.obj>