🚀 go-pugleaf

In article <1991Jun10.081924.26439@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) writes:
> ANSI does not require a prototype for non-variadic functions (as far as I
> can tell).  As a result, for a certain class of popular machines, under
> certain compiler options, defining NULL as 0 will be incorrect, while
> '(void*)0' is correct.

> And the program that would core-dump on this would be perfectly correct,
> according to ANSI.  The header file would, therefore, be wrong.

A header file #defining NULL to be 0 would _not_ be "wrong", because that
is one of the values that the standard explicitly allows.  A program which
breaks when NULL is #defined to be 0 is wrong, not the header.
Nor is it the case that (void*)0 is any more correct than 0.
It too is one of the values which the ANSI committee blessed,
and, for a certain class of popular machines, under certain compiler
options, passing (void*)0 to a function which was expecting (int*)
will break that function, whereas passing 0 would have worked.

The moral of the story is that
    -- if there is a prototype in scope, you're ok with either (void*)0 or 0
    -- if there is no prototype, but the programmer has followed the
       discipline recommended by the net.c.wizards I learned it from
       "always provide an explicit cast for NULL arguments",
       you are again ok with either (void*)0 or 0
    -- if you have an *uncast* NULL argument to a function without a
       prototype in scope, (void*) will save you in *some* systems and
       kill you in others, and so will 0.  TANSTAAFL!

My own experience is that a plain 0 is less trouble than (void*)0.
-- 
Should you ever intend to dull the wits of a young man and to
incapacitate his brains for any kind of thought whatever, then
you cannot do better than give him Hegel to read.  -- Schopenhauer.