[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Bogus ifdef guard in sys/null.h
Jukka Ruohonen <jruohonen%iki.fi@localhost> wrote:
> On Sun, Jul 18, 2010 at 03:04:15AM +0000, Valeriy E. Ushakov wrote:
>> Why is it unspecified? You cannot #undef reserved identifiers, like
>> _FOO (typical multiple-inclusion guards fall under this) or __foo.
>> Anything else - why not?
>> [#2] No other identifiers are reserved. If the program
>> declares or defines an identifier in a context in which it
>> is reserved (other than as allowed by 7.1.4), or defines a
>> reserved identifier as a macro name, the behavior is
>> The test doesn't redeclare NULL in between those two #include's that
>> both are supposed to define it, so [#2] is not violated.
>> NULL doesn't start from the undercore, so [#3] is not violated too.
> Some cases in the POSIX standard specifically indicate that the ability to
> undefine and redefine things from the standard headers was an oversight and
> may become obsolete in the future revisions.
> A good example is stupidity such as:
> #include <stdbool.h>
> #undef true
> #undef false
> #define false 1
> #define true 0
That's different, it (re)defines (not simply undef) reserved names, so
it violates 7.1.3 [#2]: "If the program declares or defines an
identifier in a context in which it is reserved (other than as allowed
by 7.1.4), or defines a reserved identifier as a macro name, the
behavior is undefined."
> Frankly I don't see much point in "#undef NULL" either, no matter
> what the standards say.
That #undef NULL example would have worked if the code to define NULL
was duplicated in each header that is supposed to define NULL, so I
don't see any harm in removing the guard from sys/null.h
Main Index |
Thread Index |