Re: Bogus ifdef guard in sys/null.h

[uwe%stderr.spb.ru@localhost (Valeriy E. Ushakov)]

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

Any references?


> 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

-uwe