[PATCH] Fix std::strchr etc. prototypes for C++

Benjamin Kosnik bkoz@redhat.com
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?

Please.
 
> 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
last looked.

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
forward.

best,
-benjamin



More information about the Gcc-patches mailing list