Re: Bogus ifdef guard in sys/null.h

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sat, Jul 17, 2010 at 06:40:13PM +0300, Stathis Kamperis wrote:
> 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.

Attached are two test programs. Both compile. So the headers obviously
define NULL. The standard doesn't give any behavior for #undef of macros
defined in systems header with the exception of macros that also exist
as functions. For those, the behavior is IMO consistent in that the
expectation is that the macro is not added again.

> 1. To align ourselves with the standard, which says that both headers
> should provide NULL.

The headers already do that. See above.

> 2. The #ifdef _SYS_NULL_H_ guard is redundant, since #ifndef NULL acts
> as one already.

It is not. It makes the second include effectively a nop with a smart
compiler.

> 3. FreeBSD and OpenBSD allow it, without any troubles.

Certain systems allow strlen(NULL) to work. That is no good
justification for doing that.

Joerg

#include <stddef.h>

int
main(void)
{
        void *p = NULL;

        return 0;
}

#include <unistd.h>

int
main(void)
{
        void *p = NULL;

        return 0;
}