Date: Sat, 15 Feb 1997 12:44:10 +0100 From: Eivind Eklund <eivind@dimaga.com> To: "Arne H. Juul" <Arne.Juul@idt.ntnu.no> Cc: chat@freebsd.org Subject: Re: NULL as ((void*)0) (was Re: strlen() question) Message-ID: <3.0.32.19970215124408.00c7e5e0@dimaga.com>
next in thread | raw e-mail | index | archive | help
(Moved to chat)
At 11:26 AM 2/15/97 +0100, Arne H. Juul wrote:
>> BTW: I just got another idea - if we can turn the definition of NULL
>> between ((void*)0) and 0 we can detect if NULL is abused if compiling on a
>> machine with different sizeof(void*) and sizeof(int). If used correctly,
>> code will be equal no matter what the definition - if used incorrectly,
>> different code should result. This can provide fairly automatic detection
>> of errors, provided we have two different builds.
>
>I think this is a good idea too, but it isn't really neccessary
>to change anything in the main source tree for this (though it
>would make it easier if there was just one place to change, of
>course). I have done a make world with (most) of the #define's
>for NULL set to ((void *)0) and have found a few minor bugs
>already (23% done). PR will follow.
Great!
(Trying to bring clarity and picking nits :)
>BTW, as far as I can see from my C standard the rules for NULL
>are pretty lax; both (1-1) and something like
> typedef enum { __ournull=0 } __dummynull;
> #define NULL __ournull
>should be legal.
When doing some tests with actual implementations, your understanding of
the standard seem to be the common one. The C FAQ claims differently, and
I've always believed it correct and been slightly puzzled at the wording of
the standard. The rationale also seems to support the 0/0L/(void*)0 variant:
[Excerpt from the ANSI C Rationale section 4.1.5]
>NULL can be defined as any null pointer constant. Thus existing code
>can retain definitions of NULL as 0 or 0L , but an implementation may
>choose to define it as (void *)0; this latter form of definition is
>convenient on architectures where the pointer size(s) do(es) not equal
>the size of any integer type. It has never been wise to use NULL in
>place of an arbitrary pointer as a function argument, however, since
>pointers to different types need not be the same size. The library
>avoids this problem by providing special macros for the arguments to
>signal, the one library function that might see a null function
>pointer.)
Anyway; obscure definitions of NULL wouldn't buy us much; the only
interesting feature of a NULL pointer is what types it introduce in a
non-pointer context, and there only seem to be three available modifiers:
(1) "Pointerness" - whether it introduce (void*), to force it to be used
only in a pointer context.
(2) Signedness - whether it is unsigned or signed
(3) Length - short/int/long
Which calculations lead up to this could be used as a stress test of the
compiler, but we're really interested in stress-testing the sources, aren't
we?
Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/
eivind@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.32.19970215124408.00c7e5e0>