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

[Gabriel Dos Reis]

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

Robert Lipe <robertlipe@usa.net> writes:

| Phil Edwards wrote:
| 
| > [As a side note, please cc any future libstdc++-v3 issues to the libstdc++-v3
| > list.  It's easy for things to get swamped in the gcc list.]
| 
| Is it correct decorum to use libstdc++ _and_ gcc/gcc-patches?

Yes, definitely.

| Here are my latest forms of punishment.
| 
| On OpenServer, the libstdc++ build of complex.cc would choke.  Looking
| at the preprocesor output[1], I found curious prototypes of the form:
| 
| # 43 "/play/egcs/libstdc++-v3/include/c/bits/std_cstdlib.h" 2 3
| 
| namespace std
| {
|   using ::div_t;
|   using ::ldiv_t;
| # 61 "/play/egcs/libstdc++-v3/include/c/bits/std_cstdlib.h" 3
|   extern "C" double atof(const char*);
| [ munch ] 
|   extern "C" ldiv_t ldiv(long int, long int);
|   extern "C" int mbtowc((wchar_t *)0, const char*, size_t);	<-----! Look

Ouch!

|   extern "C" int mbtowc(wchar_t*, const char*, size_t);
|   extern "C" int wctomb(char*, wchar_t);
|   extern "C" size_t mbstowcs(wchar_t*, const char*, size_t);
|   extern "C" size_t wcstombs(char*, const wchar_t*, size_t);
| # 115 "/play/egcs/libstdc++-v3/include/c/bits/std_cstdlib.h" 3
|   extern "C" long double strtold(const char*, char**);
| 
| }
| # 41 "/play/egcs/libstdc++-v3/include/c/bits/std_cmath.h" 2
| 
| 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

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

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com