Re: proto conflict, dwarf1 err, cpp oddity, Re: libstdc++v3 portability problems

[Robert Lipe <robertlipe at usa dot net>]

Gabriel Dos Reis wrote:
> 
> [ I propose to award a medal to Robert for heroic-resistance against
>   GCC and V3 oddities :-) ]

Thanx.  This is an award I don't really feel I deserve. I'll trade that
medal for a tree that works once again. :-)

> | I chased this back up and into the system <stdlib.h>   Sure enough, it
> | contains:
> |  
> | #define mblen(s, n)     mbtowc((wchar_t *)0, s, n)
> | 
> | I don't know the rules of C++ (and I agree this is an obnoxious system
> | definition) but I think it's quite legal for headers in C to do that.
> 
> C++ requires that functions permitted by the C standard to be defined
> as macro should be defined as actual functions.  So the above isn't
> valid for inclusion in a C++ program.
> 
> | So when we "reprototype" it, we're hosed.  Should I fixinclude this
> | away, or should libstdc++ deal with this possibility?
> 
> I think that we should be saying
> 
> 	#undef mblen

OK, but does that leave it unsolved for other C++ users of this header?  

> just after inclusion of std_cstdlib.h (actually we should also test
> whether those "functions" are defined as macros or real functions). We
> are already doing similar things in std_cctype..h

Which one? .../c/bits/... or .../c_std/bits/...?  Should I submit a
patch for the specific problem at hand adding just the above #undef or
should we speculatively "spray" undefs for other C functions in these
files?

RJL