[PATCH] Fix std::strchr etc. prototypes for C++
Thu Jan 29 19:44:00 GMT 2009
> This can't be fixed just in libstdc++, unless it implements the whole
> string.h and wchar.h on its own, but can't be fixed solely in glibc
> either, because the inlines <cstring> and <cwchar> add to provide two
> overloads instead of just one then clash with glibc prototypes.
> The following libstdc++ patch alone does nothing on current and older
> glibcs, because the __CORRECT_ISO_CPP_*_H_PROTO macros aren't
> defined, but together with the glibc patch fix this.
Yay. Nice to see this fixed. Thanks.
> Bootstrapped/regtested on x86_64-linux with patched glibc headers as
> well as old glibc headers. Ok for trunk?
> Attached is also a testcase that verifies this, but we'd probably
> need a new tcl function to check if glibc is used and has recent
> enough headers to allow the testcase to pass.
Or you could just wrap the proposed new testcase with #ifdef
__CORRECT_ISO_CPP_STRING_H_PROTO for now.
I would find that acceptable. I would like to see something checked in
to the libstdc++ testsuites to track this.
Longer term, we may want to generalize this and flip a new _GLIBCXX_
type define and use that in libstdc++ instead of __CORRECT_ISO_CPP_* if
configure probe finds the C++ includes for string.h/wchar.h has the
corrected decls. I believe some (later sun?) other libcs also do
something like what you've proposed for libc. It's been a while since I
For the moment though, let's do the expedient thing so that the
libc/libstdc++ bits are synchronized at check-in and we can move
More information about the Gcc-patches