ARM talks about 'the null pointer' (p35):

 "A constant expression (5.19) that evaluates to zero is converted
  to a pointer, commonly called the null pointer."

However, there seems to be no mentioning of 'NULL', the ANSI C null pointer
constant.  An ANSI C implementation, I believe, can define 'NULL' as
0, 0L, or (void*) 0.

Given that in C++ one must use an explicit cast to assign a (void*) to
an object pointer, does this mean:

   - a C++ programmer cannot portably use NULL (without explicit casts), or
   - C++ only allows implementations to define NULL as 0, or 0L

In article <18676@autodesk.COM>, larsn@Autodesk.COM (Lars Nyman) writes:
> ARM talks about 'the null pointer' (p35):
>
>  "A constant expression (5.19) that evaluates to zero is converted
>   to a pointer, commonly called the null pointer."
>
> [ ... ]
>
> does this mean:
>
>    - a C++ programmer cannot portably use NULL (without explicit casts), or
>    - C++ only allows implementations to define NULL as 0, or 0L

The standards committee's working paper now says

 "A constant expression (5.19) that evaluates to zero (the null
 pointer constant) when assigned to, compared with, alternated with
 (5.16), or used as an initializer of an operand of pointer type is
 converted to a pointer of that type."

and
  "NULL

 which expands to an implementation-defined C++ null pointer constant"

This supports what I believe is the committee's intent, that NULL may be
used without casts, if imported from an appropriate header.  5.19 does
not consider (void*)0 to be a constant expression, so that would not be
a valid expansion of NULL if we go by the current working paper.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com

larsn@Autodesk.COM (Lars Nyman) writes:

>ARM talks about 'the null pointer' (p35):

> "A constant expression (5.19) that evaluates to zero is converted
>  to a pointer, commonly called the null pointer."

>However, there seems to be no mentioning of 'NULL', the ANSI C null pointer
>constant.  An ANSI C implementation, I believe, can define 'NULL' as
>0, 0L, or (void*) 0.

>Given that in C++ one must use an explicit cast to assign a (void*) to
>an object pointer, does this mean:

>   - a C++ programmer cannot portably use NULL (without explicit casts), or
>   - C++ only allows implementations to define NULL as 0, or 0L

NULL is part of the Standard C library, which is not really discussed
in the ARM.  NULL is a macro defined in several Standard C headers.

The C++ Standard will make the Standard C headers and library part of
Standard C++, with a few minor modifications.  The intent is for the C
library to be used in C++ in the same way as in C, except in those few
cases where that is impossible.

In the case of the NULL macro, it must expand to a null pointer constant.
In C, (void*)0 is usually the best choice.  It is not a good choice in
C++, since you would not then be able to write
 char *p = NULL;
Conversions from void* to any other type require an explicit cast.
Accordingly, a literal zero (0 or 0L) would probably be the best choice.

A standard header used for both C and C++ would look something like this:
 #if __cplusplus
  #define NULL 0
 #else
  #define NULL ((void*)0)
 #endif

It is up to the implementation to provide a suitable definition for NULL
in the appropriate standard headers.
--

Steve Clamage, TauMetric Corp, steve@taumet.com

In article <1993Mar14.042527.25494@taumet.com> steve@taumet.com (Steve Clamage) writes:
>In the case of the NULL macro, it must expand to a null pointer constant.
>In C, (void*)0 is usually the best choice.  It is not a good choice in
>C++, since you would not then be able to write
> char *p = NULL;
>Conversions from void* to any other type require an explicit cast.
>Accordingly, a literal zero (0 or 0L) would probably be the best choice.

That can't be the whole story.  In C, "(void*)0" is a null pointer
constant, by definition.  The C Standard very carefully avoids any mention
of the type of null pointer constants.  Instead, it is littered with
paragraphs that treat null pointer constants and void* pointers separately.
For instance, in "Simple Assignment":
    ...
    * one operand is a pointer to an object or incomplete type and the
      other is a pointer to a qualified or unqualified version of void, and
      the type pointed to by the left has all the qualifiers of the type
      pointed to by the right; or
    * the left operand is a pointer and the right is a null pointer
      constant.

Apparently C++ has thrown out that first clause, so
    void *vp;
    p = vp;
is illegal.  But if C++ keeps the second clause, then either
    p = (void*)0;
is legal, or C++ has changed the definition of "null pointer constant" to
exclude "(void*)0".

In article <C3xu7H.HEB@math.uwaterloo.ca> gjditchf@plg.uwaterloo.ca (Glen Ditchfield) writes:
>In article <1993Mar14.042527.25494@taumet.com> steve@taumet.com (Steve Clamage) writes:
>>In the case of the NULL macro, it must expand to a null pointer constant.
>>In C, (void*)0 is usually the best choice.  It is not a good choice in
>>C++, since you would not then be able to write
>> char *p = NULL;
>>Conversions from void* to any other type require an explicit cast.
>>Accordingly, a literal zero (0 or 0L) would probably be the best choice.
>
>That can't be the whole story.  In C, "(void*)0" is a null pointer
>constant, by definition.

The null pointer constant is 0.  In C NULL is often defined as
"(void*)0" because of unprototyped functions:

 extern int foo();

 foo(0);

Is foo getting the integer 0 as an argument, or the null pointer
constant?  The only way to pass the latter is to say:

 foo((void *)0);

or

 foo(NULL);

Without the cast, a function expecting a null pointer gets a literal 0
instead, and the code may blow up because the bit pattern for the null
pointer does not have to be the same as that for a literal 0.  Go read
comp.lang.c, where this is all very well documented.  Let's not start
another NULL war here.

C++ doesn't have this problem due to function prototypes and stronger
type checking.  Forget NULL.  Just use 0.  Read "C++ Programming
Guidelines" (ISBN 0-911-537-10-4) by Tom Plum and Dan Saks for more
info.

--steve

Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.

In article <C3xws8.CEn@apollo.hp.com>, vinoski@apollo.hp.com (Steve Vinoski) writes:
> Let's not start another NULL war here.
> [ ... ]
> Forget NULL.  Just use 0.

Looks as if you may have fired the first volley.  What came before was
primarily a discussion of how C++ will provide compatibility with C's NULL
macro.  A side issue came up over the definition of "null pointer constant".
That C++ will provide NULL is not controversial.

Plum & Saks give a one-sided justification of the rule "use 0 not NULL".
Their main reason for this choice has faded, as implementations dealt with
the fact that using ((void*)0) for NULL was a bug.
--
Prescott K. Turner, Jr.
Liant Software Corp. (developers of LPI languages)
959 Concord St., Framingham, MA 01701 USA    (508) 872-8700
UUCP: uunet!lpi!pkt                          Internet: pkt@lpi.liant.com

In article <1993Mar16.184659.2336@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
>In article <C3xws8.CEn@apollo.hp.com>, vinoski@apollo.hp.com (Steve Vinoski) writes:
>> Let's not start another NULL war here.
>> [ ... ]
>> Forget NULL.  Just use 0.
>
>Looks as if you may have fired the first volley.  What came before was
>primarily a discussion of how C++ will provide compatibility with C's NULL
>macro.  A side issue came up over the definition of "null pointer constant".
>That C++ will provide NULL is not controversial.

Oops, you're right Scott, I guess I did unintentionally "fire the
first volley."  Guess I should follow my own advice...

thanks,
--steve

Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
Distributed Object Computing Program
Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.

In article <1993Mar16.184659.2336@lpi.liant.com> pkt@lpi.liant.com (Scott Turner) writes:
|Plum & Saks give a one-sided justification of the rule "use 0 not NULL".
|Their main reason for this choice has faded, as implementations dealt with
|the fact that using ((void*)0) for NULL was a bug.

If a programmer is working in a pure C++ environment, which correctly
defines NULL, then the programmer could indeed use that.  For those of
us still having to deal with C code and C programmers, we find not
infrequently that those programmers have #defined NULL in their header
files to be ((void*)0) or even worse things, which they "know" is the
right answer.  Thus the (justifiable IMHO) position of some C++ programmers
to "just forget NULL".  It's easy to burn a day or two tracking down
the obscure bugs that result when the "wrong" definition of NULL is being
accidentally used.