Re: Bogus ifdef guard in sys/null.h

[Stathis Kamperis <ekamperi%gmail.com@localhost>]

2010/7/17 Valeriy E. Ushakov <uwe%stderr.spb.ru@localhost>:
> Bernd Ernesti <netbsd%lists.veego.de@localhost> wrote:
>
>> On Sat, Jul 17, 2010 at 12:16:13PM +0300, Stathis Kamperis wrote:
>>
>>> in http://grok.x12.su/source/xref/netbsd/sys/sys/null.h ,
>>> the _SYS_NULL_H guard is bogus, since the whole header defines NULL
>>> only. And there's already a guard for NULL. The code as it is, breaks
>>> the following snippet:
>>>
>>> % cat t.c
>>> #include <stddef.h>
>>> #undef NULL
>>> #include <unistd.h>
>>
>> Doing that between two includes is the fault of the one who wrote that code.
>
> That was my initial reaction too, but C99 says:
>
>       7.1.3  Reserved identifiers
>
>       [#1]  Each header declares or defines all identifiers listed
>       in its associated  subclause,  and  optionally  declares  or
>       defines  identifiers listed in its associated future library
>       directions  subclause  and  identifiers  which  are   always
>       reserved  either  for  any  use  or  for  use  as file scope
>       identifiers.
>
>         -- All identifiers  that  begin  with  an  underscore  and
>            either  an  uppercase  letter or another underscore are
>            always reserved for any use.
>
>       ...
>
>         -- 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).
>
>       ...
>
>       [#3]  If  the  program  removes  (with  #undef)  any   macro
>       definition of an identifier in the first group listed above,
>       the behavior is undefined.
>
> 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.
>
> -uwe
>
>

Thanks for the quote!
Yeh, I agree that the behavior is unspecified, starting from the
#undef of the identifier until the inclusion of a header that is
required to define it. At least this is how I perceive it.

On a general note, I don't think that unspecified/undefined behavior
means that we should come up with the least convenient solution, from
the application developer's POV. Especially, when doing otherwise,
wouldn't cost us a thing.

Anyway, I don't argue to change the status quo. I have already fixed
the "offending" code and it works fine, even in NetBSD.


Best regards,
Stathis