This is the mail archive of the libstdc++@sources.redhat.com mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: proto conflict, dwarf1 err, cpp oddity



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]