dn> then use NULL whenever a null pointer is required. This is a stylistic
 dn> convention only; the preprocessor turns NULL back to 0 which is then
 dn> recognized by the compiler (in pointer contexts) as before. In particular,
 dn> a cast may still be necessary before NULL (as before 0) in a function call
 dn> argument.  (The table under question 1.2 above applies for NULL as well as
 dn> 0.)

I find this hard to believe, that a cast is ever required before NULL, in
an ANSI-conforming environment.

 dn>        #define NULL (char *)0

 dn> wouldn't that make function calls which pass an uncast NULL work?

 dn> A:  Not in general.  The problem is that there are machines which use
 dn> different internal representations for pointers to different types of
 dn> data. The suggested #definition would make uncast NULL arguments to
 dn> functions expecting pointers to characters to work correctly, but pointer
 dn> arguments to other types would still be problematical, and legal
 dn> constructions such as

Here is their explanation, which does make sense.

 dn> Nevertheless, ANSI C allows the alternate

 dn>    #define NULL ((void *)0)

 dn> definition for NULL.  Besides helping incorrect programs to work (but only
 dn> on machines with homogeneous pointers, thus questionably valid assistance)

I just quibble about the homogenous requirement.  I would suggest that a
machine with non-homogenous pointers would require all pointers to be cast
to void by the compiler before being passed to a function.  What do you
reckon? BFN.

Paul

--- GoldED/2 2.42.G1114