matt@physics16.berkeley.edu (Matt Austern) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>
>> [we could add a new keyword __builtin_null_pointer, and then]
>> #define NULL as __builtin_null_pointer in the system header files,
>
>I don't deny that this is possible (and even easy, for some compilers).
>Nor do I deny that it is conforming.
>
>I do, however, wonder whether this is really much better than "#define
>NULL 0".  Could a user ever see any difference?  Or, to put it
>differently: is there any conceivable definition of NULL that behaves
>differently than 0 but that is standard-conforming?  (I suspect that
>the answer is no, but I don't claim to have a proof.)

I claim that the answer is yes.  For example, a compiler could emit
diagnostics for the following C++ code, which converts NULL to a
non-pointer type at the lines marked /* error */.  Such diagnostics
would not be issued by existing implementations that #define NULL as 0.

 #include <stddef.h>

 int bar1() { return NULL; } /* error */
 double bar2() { return NULL; } /* error */
 int* bar3() { return NULL; } /* ok */
 void* bar4() { return NULL; } /* ok */
 double* bar5() { return NULL; } /* ok */

 void foo1(void *p) {}
 void foo2(int *p) {}
 void foo3(int p) {}
 void foo4(double p) {}

 int main() {
    int *p = NULL; /* ok */
    double *q = NULL; /* ok */
    int x = NULL; /* error */
    double y = NULL; /* error */
    foo1(NULL);  /* ok */
    foo2(NULL);  /* ok */
    foo3(NULL);  /* error */
    foo4(NULL);  /* error */
    return 0;
 }

To some extent, this just begs the question as to whether the code
above is really non-conforming or not - is the compiler allowed to
reject the above code?  Such code is definitely not strictly conforming
C, since NULL can be defined as (void *)0 in C; I claim that it is also
not strictly conforming C++, on the basis that my implementation has
satisfied the requirements which the ANSI C standard places on the
definition of NULL, by defining NULL as the implementation defined null
pointer constant `__builtin_null_pointer'; and on the basis that my
implementation is otherwise conformant, and that it rejects the above
code.

Another difference is that such an implementation would _not_
issue a diagnostic for C++ code such as the following:

 #include <stddef.h>

 void ambiguous(long) {}
 void ambiguous(char *) {}

 int main() {
    ambiguous(NULL);
    return 0;
 }

Finally, such an implementation could also _optionally_ issue style warnings
for
 int *x = 0;
suggesting the use of NULL instead of 0.  In the distant future, these
warnings could be made the default, and in the _very_ distant future
these warnings could finally be upgraded to errors :-)

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

In article <9328317.10666@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU
(Fergus James HENDERSON) writes:

|> matt@physics16.berkeley.edu (Matt Austern) writes:

|> >fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

|> >> [we could add a new keyword __builtin_null_pointer, and then]
|> >> #define NULL as __builtin_null_pointer in the system header files,

|> >I don't deny that this is possible (and even easy, for some compilers).
|> >Nor do I deny that it is conforming.

|> >I do, however, wonder whether this is really much better than "#define
|> >NULL 0".  Could a user ever see any difference?  Or, to put it
|> >differently: is there any conceivable definition of NULL that behaves
|> >differently than 0 but that is standard-conforming?  (I suspect that
|> >the answer is no, but I don't claim to have a proof.)

|> I claim that the answer is yes.  For example, a compiler could emit
|> diagnostics for the following C++ code, which converts NULL to a
|> non-pointer type at the lines marked /* error */.  Such diagnostics
|> would not be issued by existing implementations that #define NULL as 0.

   [large number of examples deleted...]

For the point in question: at present, there is no C++ standard, so
one cannot talk of standards conforming or not.  Fergus Henderson's
implementation, for example, allows better type safety, while not
breaking any reasonable programs.  Of course, it might break a few
programs that deserved to be broken anyway:-).

In fact, I would consider Fergus Henderson's implementation a strong
argument in favor of writing the standard in such a way as to at least
make such controls legal, if not obligatory.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung