Re: bug(s) in 2.5.19 skel.c

[Hans-Bernhard Broeker]

On 17 Sep 2002, Akim Demaille wrote:

> This is very true theoretically, but I never saw evidence of practical
> existence.  This is looking for additional burden where there is,
> IMHO, already enough to think about.  For instance, test snippets from
> Autoconf do assume NULL == 0, and there has never been any bug
> report.

NULL==0 is perfectly fine.  Assigning or initializing a pointer by "zero"
is, too.  

It's trying to create a null pointer by writing zero bytes into the memory
holding a pointer variable that doesn't work.  

Think of platforms where pointers don't natively exist, or which use some
special flag bits in the pointer itself to signal that a pointer points to
data memory instead of code (Harvard architecture, as opposed to the
von-Neumann one), or to give the alignment of the pointer.  Or segmented
architectures where ("far") pointers have to contain a segment index
number, but segment number zero is not available to the C toolchain
makers.

The C compiler can catch all such tricky cases if you use correctly built
null pointer constants, like NULL or (whatever *)0, or simply 0 if it
appears in a "pointer context". The compiler cannot work this magic if you
don't let it know that you're trying to construct a pointer, and the
result is undefined behaviour.  Which is about the worst class of bug
a C program can have and still make it through the compiler.

-- 
Hans-Bernhard Broeker (address@hidden)
Even if all the snow were burnt, ashes would remain.