tech-userlevel archive

[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 Joerg Sonnenberger <>:
> On Sat, Jul 17, 2010 at 06:40:13PM +0300, Stathis Kamperis wrote:
>> 2010/7/17 Joerg Sonnenberger <>:
>> > 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:
>> >>
>> >>
>> >> 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.
I didn't say that they never define it. I said that they don't always
do. You can write infinite many test programs where NULL is provided
by both, but that doesn't cancel out the fact that there's one corner
case that it isn't.

>> 1. To align ourselves with the standard, which says that both headers
>> should provide NULL.
> The headers already do that. See above.
They don't. 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.
Ah, right. I had in mind what FreeBSD does:

which kills two birds, with one stone.

>> 3. FreeBSD and OpenBSD allow it, without any troubles.
> Certain systems allow strlen(NULL) to work. That is no good
> justification for doing that.
But we don't discuss strlen(NULL). Nor does standard has any
requirements on it. Also, that was a response to you saying that
"which would break rather badly if this behavior was actually
allowed". There are systems that they allow it, without any breakage.

All-in-all, I don't mind leaving it as it is. It was just something
that broke for me and drew my attention.


Home | Main Index | Thread Index | Old Index