This is the mail archive of the
libstdc++@sources.redhat.com
mailing list for the libstdc++ project.
Re: proto conflict, dwarf1 err, cpp oddity
- To: libstdc++ at gcc dot gnu dot org, robertlipe at usa dot net
- Subject: Re: proto conflict, dwarf1 err, cpp oddity
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Mon, 11 Dec 2000 12:32:40 -0800
>> | 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?
It shouldn't.
There should be non-macro versions of these functions in the unixware
header, and the macro vs function versions are probably controlled by
(yet another) macro. In this case, what you can do is make a
config/os/unixware
and then
config/os/unixware/bits/os_defines.h
where you define the bits to make unixware work.
If this is not the case, then you'll need to implement some kind of
macro-capture. This is done in the c_std headers, you might want to
check out what they do. I'm hoping this won't be necessary though.
>> 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?
You should just do it for include/c/bits/
The other is the shadow header include directory. I agree in advance
the naming is a bit off.
You should submit a patch for all the bits in stdlib.h, not just mblen.
thanks,
benjamin