correct "C" headers, higher priority

[scott snyder]

hi -

Benjamin Kosnik <bkoz@redhat.com> writes:
> There are now a series of bugs in GNATS about strchr, strcpy, etc all 
> being ambiguously declared, or not declared, etc. It's something that 
> everybody is going to run into and yes, it can be worked around but it's 
> kind of lame to have everything else working pretty well and have 
> something so basic tripping people up.
> 
> In any case, even though Mark is not requiring it for gcc-3, I think a 
> real effort should be made to make sure shadow-headers or some other, 
> more conformant than c_std option, is in working order for this release.

I'd be leery of trying to get the full c_shadow stuff working on the
sort of timescale we're talking about.

I was at one point trying to use the c_shadow implementation.
But it was uphill going --- mainly because whenever you tried to use
a header or identifier not in the C++ standard, things didn't work.
So i spent a while writing additional c_shadow wrappers for all
the other, non-C++ headers our code was using (think things
like sys/sem.h, arpa/inet.h, dirent.h, ucontext.h ...) plus adding
a whole bunch of additional identifiers to the existing headers
(drand48, mkstemp, pthread_join, sigprocmask, setsid, ...).
The result was pretty messy, and not particularly portable.

What i have done to work around the current string.h problems is
less ambitions.  I created a string.h in include/c_std and install
it with the headers.  The contents of this string.h look like this:

#include <cstring>
#include_next <string.h>
#ifndef memset
using std::memset;
#endif
...   (and similarly for the other string functions)

Note the absence of header guards.  That's because this file could
have gotten included first from <cstring>, where `memset' etc., are
#defined to different names.  That's also why i have the #ifndef's
above.

Really ugly --- but for this simple test program

#include <string.h>
#include <cstring>
using namespace std;

const char* foo (const char* s)
{
  return strchr (s, 'a');
}


it works for either ordering of the includes, regardless of whether
or not the using directive is present.

Maybe a fix along those lines would be better for 3.0, pending a proper
fix for this stuff later on.

sss