Re: Bogus ifdef guard in sys/null.h

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

2010/7/17 Joerg Sonnenberger <joerg%britannica.bec.de@localhost>:
> On Sat, Jul 17, 2010 at 12:16:13PM +0300, Stathis Kamperis wrote:
>> POSIX says that both stddef.h and unistd.h shall provide NULL. This
>> isn't just a thought experiment. It actually broke a test from here:
>> http://www.itl.nist.gov/div897/ctg/posix_form.htm
>>
>> Please consider changing it, or explain why it shouldn't.
>
> Both headers provide NULL.
They don't, always. If they did, the code would compile.

>I remember certain headers are allowed to
> include others to provide the complete API, which would break rather
> badly if this behavior was actually allowed.
How could it break? NULL is defined only if hasn't been defined yet.
Also, FreeBSD doesn't have an extra #ifdef guard and it seems to be
doing fine. OpenBSD doesn't have at all a separate null.h. They just
check against it in every file that is supposed to define it
(stddef.h, string.h, unistd.h). So both FreeBSD and OpenBSD allow for
this behavior and the code compiles clean[1].

>
> So let me turn your question back -- why should this behavior be
> allowed?
>
> Joerg
>
1. To align ourselves with the standard, which says that both headers
should provide NULL.
2. The #ifdef _SYS_NULL_H_ guard is redundant, since #ifndef NULL acts
as one already.
3. FreeBSD and OpenBSD allow it, without any troubles.



Cheers,
Stathis

[1]I'm not advocating that it's good code.