[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Bogus ifdef guard in sys/null.h
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
> -- 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
> [#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.
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.
Main Index |
Thread Index |