tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Bogus ifdef guard in sys/null.h
Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:
> On Sun, Jul 18, 2010 at 03:04:15AM +0000, Valeriy E. Ushakov wrote:
>> Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:
>>
>> > On Sat, Jul 17, 2010 at 08:20:45PM +0000, Valeriy E. Ushakov wrote:
>> >> I read [#3] to mean that you shouldn't #undef only "identifiers that
>> >> begin with an underscore and either an uppercase letter or another
>> >> underscore" (the first item in the list in [#1]), and that it doesn't
>> >> cover all items from the list.
>> >
>> > Yes, that part doesn't apply. The only other part that talks about
>> > #undef of macros is if they have functions as backing. E.g. isalpha().
>> > So from my reading of the standard, it is simply unspecified.
>>
>> Why is it unspecified? You cannot #undef reserved identifiers, like
>> _FOO (typical multiple-inclusion guards fall under this) or __foo.
>> Anything else - why not?
>
> NULL is not reserved, so this complete block doesn't apply.
It is reserved b/c of the following:
7.1.3 Reserved identifiers
-- Each macro name in any of the following subclauses
(including the future library directions) is reserved
for use as specified if any of its associated headers
is included; unless explicitly stated otherwise (see
7.1.4).
> The only other place where C99 defines behavior for #undef of macros
> defined by system header is when talks about the macro/function
> dualism. In that case the intention seems to be strongly that "if I
> #undef the macro, I mean it".
That passage in 7.1.4, unfortunately, is worded such that it's hard to
read it as defining anything, looks more like a hint how to refer to
an actual function even if function-like macro is present ("oh, btw,
and you can also #undef it, but you knew that already, right?").
Anyway, why don't we just nuke the guard?
-uwe
Home |
Main Index |
Thread Index |
Old Index