In a previous article,  Paul Black  <paul.black@oxsemi.com> writes:
>"William M. Miller" <wmmNOwmSPAM@fastdial.net.invalid> wrote:
>>
>> Ron Natalie <ron@sensor.com> wrote:
>> >Actually the latter statement is untrue.  The PDP-11 UNIX that
>> >was the early C platform had the first instruction of the
>> executed
>> >program at location zero.
>>
>> I would consider that "not useful" -- there's no reason a
>> non-null pointer would ever point to that location.
>
>Not useful? There are platforms out there where have address 0 holds
>important information.

I think you came in late on this discussion.  This is exactly the
point I was making -- the original Unix platforms were able to use
all-bits-zero for the null pointer because there was nothing at
absolute location zero that needed to be pointed at.  As a result,
an all-bits-zero pointer was distinct from every "useful" pointer,
which is the primary requirement for the null pointer value.

Because "there are platforms out there where address 0 holds
important information" (and presumably a program might need to
have a non-null pointer reference that information), standard C
and C++ does not require that the value of a null pointer be all-
bits-zero.

>
>> That's one way of dealing with the problem -- making location
>> 0 a reserved address allows you to keep the all-bits-zero
>> runtime value.
>
>That now excludes such systems from having ANSI C/C++.

No it doesn't.  An implementation is at liberty to choose whatever
representation it wishes for the null pointer value, as long as no
actual pointer that refers to an object or function will have that
value.  If the null pointer value is an actual address, it is
therefore the implementation's responsibility to ensure that no
object or function is ever located at that address, i.e., that it's
a reserved address.

>
>>  When the value of the null pointer was being
>> discussed at Stratus, it was pointed out that often null
>> pointers are used to access members of structures, so the
>> effective address isn't the null pointer value itself but
>> rather the null pointer value plus some (usually small) offset.
>> Since the goal was to make both read and write accesses using
>> the null pointer generate a hardware fault, that meant a range
>> of addresses needed to be dedicated.  That wasn't practical
>> using absolute location 0 in our architecture because the 68000
>> processor makes zero-page references especially efficient, so
>> various data used in time-critical operations were placed
>> there.  That's why the null pointer value was placed way high
>> in the address space, to allow a whole page to catch "null
>> plus offset" dereferences without using up the valuable resource
>> of page 0.
>
>You have condradicted yourself by describing a reason why a non-null
>pointer would point at address 0.

No, that's exactly the point I was making, giving a rationale for
why, on some systems, the null pointer value might not be all-bits-
zero.

-- William M. Miller


     -----  Posted via NewsOne.Net: Free Usenet News via the Web  -----
     -----  http://newsone.net/ --  Discussions on every subject. -----
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Am 07.07.00, 05:48:23, schrieb Paul Black <paul.black@oxsemi.com> zum The=
ma=20
Re: Does NULL always =3D=3D 0 ?:

> "William M. Miller" <wmmNOwmSPAM@fastdial.net.invalid> wrote:
> >
> > Ron Natalie <ron@sensor.com> wrote:
> > >Actually the latter statement is untrue.  The PDP-11 UNIX that
> > >was the early C platform had the first instruction of the
> > executed
> > >program at location zero.
> >
> > I would consider that "not useful" -- there's no reason a
> > non-null pointer would ever point to that location.

> Not useful? There are platforms out there where have address 0 holds
> important information.

I guess you misunderstood. I read William as saying "The memory location=20
of the first instruction of the program being executed is 'not useful' to=
=20
that program.  There's no reason a non-null pointer would ever point to=20
that location (from within that program). The address of that location=20
can be used as a null pointer value."

Of course there are platforms where address 0 holds 'useful' information,=
=20
i.e. information that is important to the C++ program being executed.=20
Accessing the location of it's own first instruction cannot usually be=20
done in a C++ program. If it can be done it will have to use very=20
low-level and platform-dependent means anyways.
I'm not sure that you even could write '&::main'. If you can, it still=20
would yield a non-null function pointer value. But that same address=20
could be used as a null object pointer value.

> > That's one way of dealing with the problem -- making location
> > 0 a reserved address allows you to keep the all-bits-zero
> > runtime value.

> That now excludes such systems from having ANSI C/C++.

No, on 'such systems' you would not choose that 'way of dealing with the=20
problem'. Rather you would choose a null pointer value so as not to=20
interfere with valid and necessary memory locations. This of course would=
=20
mean that a null pointer value weren't be all-bits-zero.

--
J=F6rg


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Black <paul.black@oxsemi.com> wrote:
: "William M. Miller" <wmmNOwmSPAM@fastdial.net.invalid> wrote:
: >
: > Ron Natalie <ron@sensor.com> wrote:
: > >Actually the latter statement is untrue.  The PDP-11 UNIX that
: > >was the early C platform had the first instruction of the
: > >executed program at location zero.
: >
: > I would consider that "not useful" -- there's no reason a
: > non-null pointer would ever point to that location.
:
: Not useful? There are platforms out there where have address 0 holds
: important information.

William Miller wasn't denying that -- indeed, he affirmed it himself
in the article you are quoting and in an earlier article in this
thread.  The sentence you quote merely denies that the PDP-11 Unix is
such a platform (or, more exactly, that it would be useful for a C
program to access location zero on the PDP-11 Unix).

--
John Rickard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <1edfds7.jl040xf9wpeyN@slip139-92-12-35.hm.de.prserv.net>,
  joerg.barfurth@attglobal.net (Joerg Barfurth) wrote:
> Paul Black <paul.black@oxsemi.com> wrote:
>
> > > > That now excludes such systems from having ANSI C/C++.
> > >=20
> > > Why?
> >=20
> > Because in such systems location 0 holds something useful, it can't
be
> > used be used for both a null pointer and a valid location. It's
either
> > one or the other.
>
> OTOH, it is perfectly possible to use the address of something useful
as
> a null pointer constant. Dereferencing null pointers is undefined. An
> implementation may produce crashes, but it is not required to do so.
On
> the contrary: The implementation may define the result of
dereferencing
> a null pointer (e.g. as accessing memory location 0).

This is a good point, and I'm sorry if my example obscured it.
The only requirement for a null pointer is that it be distinct
from every object and function that can be created within the
language.  As long as no object can be allocated at that
address and no function located at that address, an
implementation is free to use any value it wants for the null
pointer.  That's what an earlier poster was saying about the
Unix implementations that reserved location 0 -- preventing
the compiler/runtime from allocating objects there made
all-bits-zero a perfectly acceptable value for the null pointer.
If the system (not the language allocation) puts useful
information at the address referenced by the null pointer
value, it's perfectly okay for the language implementation to
allow read and/or write access to that information via the null
pointer.

In the case I was referring to, we felt that having a memory
access via the null pointer generate a hardware fault was a
useful debugging tool.  However, that feature is _not_ mandated
by the Standard, it was a design decision on the part of the
Stratus system architects.

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3965168A.494BB53C@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> "William M. Miller" wrote:
> >
> > Ron Natalie <ron@sensor.com> wrote:
> > >
> > >
> > >wmm@fastdial.net wrote:
> > >> The second was that absolute location 0 was not a
> > >> useful location in the hardware and/or operating system
> > >> on which C originally ran.
> > >
> > >Actually the latter statement is untrue.  The PDP-11 UNIX that
> > >was the early C platform had the first instruction of the
> > executed
> > >program at location zero.
> >
> > I would consider that "not useful" -- there's no reason a
> > non-null pointer would ever point to that location.
>
> Why not? Depending upon the implementation, a function pointer of the
> correct (implementation-defined) type, initialized with all bits zero,
> might represent a validly executable function on such a platform, one
> which has the effect of restarting the program from scratch...
>
> Even more dangerous, and even less portable, would be the assignment
of
> that address to a data pointer, which could then be used to implement
> self-modifying code...

"Never say 'never.'" :-)

Touche -- within those parameters, I stand corrected.

--
William M. Miller, wmm@fastdial.net
Vignette Corporation (www.vignette.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Black wrote:
....
> This is what the OP said: "there's no reason a non-null pointer would
> ever point to that location." The contradiction is that in the case
> described above, the pointer is non-null and points at location 0.

But what does that contradict? The statement about "that location"
refered very specifically to a PDP-11. The "case above" was specifically
a 68000 processor. I don't know what CPU the PDP-11 had, but I doubt it
was a 68000.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I found out something interesting. NULL is defined to be 0. If you look in
the Windef.h line 56 you will find this:
#define NULL        0
this if I'm not mistaken says that everywhere the word 'NULL' is quoted put
a 0 so in fact NULL is then defined to be 0. If you look even further you
will see:
#ifndef FALSE
#define FALSE               0
#endif

#ifndef TRUE
#define TRUE                1
#endif

-Nick Dziedzic-


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Wed, 28 Jun 2000, Jim Dziedzic wrote:

> #define NULL        0

This makes sense.  It's what you'd expect.  My question was, has anyone
ever implemented a system with

#define NULL -1

or some other value, or can NULL have a more esoteric meaning (like
Not-A-Number floating point values, or Not-A-Thing value for IA-64,
certainly neither of which ==0).

> #ifndef FALSE
> #define FALSE               0
> #endif
>
> #ifndef TRUE
> #define TRUE                1
> #endif

I believe this is Microsoft-specific.  The labels 'true' and 'false'
(lowercase) are part of the C/C++ definition, are they not?  Microsoft
often returns (uppercase) TRUE or FALSE from APIs and classes, such
as:

CWnd::ShowWindow(BOOL nCmdShow=TRUE);

whereas for things like

bool keepgoing=true;
while (keepgoing)
{//do the loop}

they use lowercase.

Richard.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Wed, 28 Jun 2000 08:22:40 CST, "Jim Dziedzic"
<JDZIEDZIC@prodigy.net> wrote:

>I found out something interesting. NULL is defined to be 0. If you look in
>the Windef.h line 56 you will find this:
>#define NULL        0
>this if I'm not mistaken says that everywhere the word 'NULL' is quoted put
>a 0 so in fact NULL is then defined to be 0. If you look even further you
>will see:
>#ifndef FALSE
>#define FALSE               0
>#endif
>
>#ifndef TRUE
>#define TRUE                1
>#endif

Since this is comp.STD.c++, discussions should focus on the
requirements of the language definition, not the contents of a
particular header file unique to one operating system.

The language definition requires that certain standard headers define
a macro spelled NULL to be an integer constant expression having the
value zero. The usual way to do that is
 #define NULL 0
but that is not the only possible way to meet the requirement.

Since Windef.h is not a standard C++ header, it can contain anything
its creators want. But no stanard header can define macros spelled
TRUE or FALSE, because those identifiers are reserved for use by the
programmer, not the C++ implementation.
---
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jim Dziedzic wrote:
>
> I found out something interesting. NULL is defined to be 0. If you look in
> the Windef.h line 56 you will find this:

Windef.h is not a standard header. Therefore, it's contents aren't
likely to be relevant to a discussion on this newsgroup, which is
devoted to the C++ standard.
NULL is supposed to be #defined in <cstddef>, <cstring>, <ctime>,
<cwchar>, <clocale>, <cstdio>, <stddef.h>, <time.h>, <string.h>,
<wchar.h>, <locale.h>, and <stdio.h>. Whether it's defined anywhere else
is up to the implementation.

> #define NULL        0

You shouldn't assume anything more than what the standard actually
guarantees: that NULL is an integer constant expression with a value of
0. Being '0' is the simplest way to achieve that result, and I'm unaware
of any good reason for defining it as anything more complicated.
Nonetheless, DON'T make that assumption.

> this if I'm not mistaken says that everywhere the word 'NULL' is quoted put
> a 0 so in fact NULL is then defined to be 0. If you look even further you
> will see:
> #ifndef FALSE
> #define FALSE               0
> #endif
>
> #ifndef TRUE
> #define TRUE                1
> #endif

That's completely irrelevant to this newsgroup. Those macros aren't
defined by the standard anywhere. On the other hand, the keywords
'false' and 'true' are defined by the standard.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jim Dziedzic wrote:

> Consider this then! The NULL pointer is a symbol that is used by the
> compiler to return a specific value when used in certain context such as
> when it is used in-
> if (!pClass) the compiler substitutes the false value in because the pointer
> is NULL and the if (!pClass) statement is calling for a true or false value
> which is determined when the '!' was typed.
>
> -Nick Dziedzic-

But according to the C++ Standard, NULL is not a null pointer.  NULL isn't
even a pointer.  It's a "null pointer constant", which is an integral constant
which compares equal to 0.

IMO, and in those of any others, this is an error; NULL would have been
better defined as compiler magic, but that's not how C++ does it (or C for
that matter).

The fact that (!pointer) works is entirely separate from the issue of what
NULL is.

Saying "the pointer is null" makes sense (it's a null pointer) but saying that
a pointer "is NULL" doesn't make sense because NULL is not a pointer value.

Apologies for the pedantry, but this is a Standards newsgroup!

-- James Dennett

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Richard John Cavell wrote:
>
> On Wed, 28 Jun 2000, Jim Dziedzic wrote:
>
> > #define NULL        0
>
> This makes sense.  It's what you'd expect.  My question was, has anyone
> ever implemented a system with
>
> #define NULL -1
>
> or some other value, or can NULL have a more esoteric meaning (like
> Not-A-Number floating point values, or Not-A-Thing value for IA-64,
> certainly neither of which ==0).

If it isn't ==0, then it doesn't qualify as a null pointer constant. If
it doesn't have an integer type, it doesn't qualify as a null pointer
constant. And if it isn't a null pointer constant, it can't be the value
of NULL in a conforming implementation of C++.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jim Dziedzic wrote:
>
> Consider this then! The NULL pointer is a symbol that is used by the
> compiler to return a specific value when used in certain context such as

In C++ NULL is not a pointer.

It is a symbol that evaluates to a null pointer constant.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi All,
 I seem to remember reading something about this in C/C++ Users Journal
and they said it could either be 0 or a null pointer I don't remember the
exact format.  You could go to their web site www.cuj.com and search :)
TTFN,
 /mtb

On Wed, 28 Jun 2000 23:18:40 CST Richard John Cavell wrote:

> On Wed, 28 Jun 2000, Jim Dziedzic wrote:

>> #define NULL        0

> This makes sense.  It's what you'd expect.  My question was, has anyone
> ever implemented a system with

> #define NULL -1

> or some other value, or can NULL have a more esoteric meaning (like
> Not-A-Number floating point values, or Not-A-Thing value for IA-64,
> certainly neither of which ==0).

>> #ifndef FALSE
>> #define FALSE               0
>> #endif
>>
>> #ifndef TRUE
>> #define TRUE                1
>> #endif

> I believe this is Microsoft-specific.  The labels 'true' and 'false'
> (lowercase) are part of the C/C++ definition, are they not?  Microsoft
> often returns (uppercase) TRUE or FALSE from APIs and classes, such
> as:

> CWnd::ShowWindow(BOOL nCmdShow=TRUE);

> whereas for things like

> bool keepgoing=true;
> while (keepgoing)
> {//do the loop}

> they use lowercase.

> Richard.

> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Richard John Cavell <rjcavell@student.unimelb.edu.au> wrote in message
news:Pine.OSF.4.10.10006281249150.31671-100000@cassius.its.unimelb.edu.au...
> On Wed, 28 Jun 2000, Jim Dziedzic wrote:
>
> > #define NULL        0
>
> This makes sense.  It's what you'd expect.  My question was, has anyone
> ever implemented a system with
>
> #define NULL -1
>
> or some other value, or can NULL have a more esoteric meaning (like
> Not-A-Number floating point values, or Not-A-Thing value for IA-64,
> certainly neither of which ==0).
>

A null pointer constant is an integral constant evaluating to 0. (-1)
doesn't
fit this description.

NULL is an implementation-defined null-pointer constant, and should
therefore also evaluate to 0.

e.g.
#define NULL (1-1)
#define NULL 0
#define NULL 0L
#define NULL 0UL

and so on.

Scott Condit

<snip>

> Richard.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Richard John Cavell wrote:
>
> On Wed, 28 Jun 2000, Jim Dziedzic wrote:
>
> > #define NULL        0
>
> This makes sense.  It's what you'd expect.  My question was, has anyone
> ever implemented a system with
>
> #define NULL -1
>
> or some other value, or can NULL have a more esoteric meaning (like
> Not-A-Number floating point values, or Not-A-Thing value for IA-64,
> certainly neither of which ==0).

In C++ the NULL macro is required to be defined by the implementation
as an integer constant expression with value zero. The usual definition
is 0 (or 0L), although other definitions are possible.

The NULL macro represents a null pointer constant. Do not confuse a
null pointer constant, which is a source-code construct, with the
way null pointers are represented in the target machine.

The target machine is not restricted by the C++ language definition in
how it represents null pointers. It is up to the compiler to make the
appropriate conversions.  (Similarly, the language definition does
not dictate how floating-point numbers are represented. If you
write 0.0, it is up to the compiler to generate the bit pattern
appropriate for a floating-point zero.)

An implementation could choose use the same bit pattern as an integer
-1 to represent a null pointer. In that case, the compiler would
convert null pointer constants in source code to that bit pattern when
it generates object code.  But in writing source code, all you need to
know is that you write 0 or NULL when you mean "null pointer."

--
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Richard John Cavell wrote:
>
> On Wed, 28 Jun 2000, Jim Dziedzic wrote:
>
> > #define NULL        0
>
> This makes sense.  It's what you'd expect.  My question was, has anyone
> ever implemented a system with
>
> #define NULL -1

It would not be legal C++.  NULL must have value 0.

That's not to say that a machine couldn't use all ones as the internal representation
of a null pointer.  It would be incumbant that when a compiler sees:
 ptr = 0;
to store all ones into the ptr and when
 ptr == 0
is encountered, it must return true when the all ones is found in the ptr.

>
> I believe this is Microsoft-specific.  The labels 'true' and 'false'
> (lowercase) are part of the C/C++ definition, are they not?  Microsoft
> often returns (uppercase) TRUE or FALSE from APIs and classes, such
> as:
>
> CWnd::ShowWindow(BOOL nCmdShow=TRUE);

Furhtermore BOOL is an int (not a bool type).  This is mostly backwards compatibility
with an infractructure which really is C anyhow (despite the trivial wrapping of classes
around it).

>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David Tribble <david@tribble.com> wrote:
>> It's been posted here several times before, but here is a more
>> type-safe version of 'null' that makes it look and act more like a
>> built-in keyword:
>>
>>    class Null_
>>    {
>>    public:
>>        template <class T> operator T*() const
>>        {
>>            return ((T*) 0);
>>        }
>>    private:
>>        /*void*/    Null_(const Null_ &r);
>>        void        operator &();
>>    };
>>
>>    const Null_     null;       // Generic null pointer constant

Mike Davies wrote:
> I don't understand what the advantage of this is either?

Perhaps an example will illustrate:

    extern void  bar(int i);
    extern void  bar(int *ip);

    extern void  baz(int *ip);
    extern void  baz(char *cp);

    void foo(int i, int *ip)
    {
        if (ip == null) ...       // okay
        ip = null;                // okay

        if (i == null) ...        // error
        i = null;                 // error

        bar(null);                // okay
        baz(null);                // ambiguous

        std::memset(ip, null, sizeof(int));  // error
    }

Substituting 'NULL' for 'null' in the code above yields code that
will compile without warnings.

In other words, 'null' is more type safe and less ambiguous than
'NULL' or 0.  Its definition approaches what we would expect from
a built-in 'null' keyword.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <395802F8.CFF6D3F3@wizard.net>, James Kuyper
<kuyper@wizard.net> writes
>NULL is "a" null pointer constant (NPC), not "the" NPC. There are a
>practical infinity of NPCs, including 0, (1-1), (2-2), (1+2-3), (2*2-4),
>(3/2-1), etc.

No, those are just different ways of writing it:)


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Dennett wrote:
> But according to the C++ Standard, NULL is not a null pointer.
> NULL isn't even a pointer.  It's a "null pointer constant", which is
> an integral constant which compares equal to 0.
>
> IMO, and in those of any others, this is an error; NULL would have
> been better defined as compiler magic, but that's not how C++ does it
> (or C for that matter).

You're not alone in your opinion.  Many of us have argued for a
'null' keyword, or at least a standard 'null' constant, that acts
more like what we would expect a "null pointer constant" to act like.
The situation is not so bad in C, but it's terrible in C++.

(See my particular entry into the fray, dated 1997, at
<http://david.tribble.com/text/c9xnull.txt>.  Also see my recent
post on this thread, giving code for a 'null' constant that comes
pretty close.)

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jim Dziedzic wrote:
>> #define NULL    0

Richard John Cavell wrote:
>> This makes sense.  It's what you'd expect.  My question was, has
>> anyone ever implemented a system with
>>
>> #define NULL -1
>>
>> or some other value, or can NULL have a more esoteric meaning (like
>> Not-A-Number floating point values, or Not-A-Thing value for IA-64,
>> certainly neither of which ==0).

James Kuyper wrote:
> If it isn't ==0, then it doesn't qualify as a null pointer constant.
> If it doesn't have an integer type, it doesn't qualify as a null
> pointer constant. And if it isn't a null pointer constant, it can't
> be the value of NULL in a conforming implementation of C++.

James is correct about the proper definition of 'NULL'.

However, that does not mean an implementor can't choose whatever
bit pattern it wants to represent a null pointer value.  If I'm
not mistaken, IBM CICS uses a null pointer with the upper bit set,
i.e.:

    void *p = (void *)0x80000000;

    if (p == NULL) ...    // true on CICS

However, to be conforming, it must also allow comparisons of null
pointers to zero:

    p = 0;

    if (p == 0) ...       // true always, everywhere

Which means that 'NULL' must be defined as 0, regardless of the
actual null pointer bit pattern.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Mike Buchanon wrote:
>
> Hi All,
>  I seem to remember reading something about this in C/C++ Users Journal
> and they said it could either be 0 or a null pointer I don't remember the
> exact format.  You could go to their web site www.cuj.com and search :)

I don't need to search, the C++ standard is quite clear on it, it must be
an INTEGERAL constant expression.

In C it can be (void*)0, but in C++ not only is this not allowed, it won't
work.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Thu, 29 Jun 2000, David R Tribble wrote:

> > IMO, and in those of any others, this is an error; NULL would have
> > been better defined as compiler magic

Well, I guess that's what I'm proposing - that NULL be compiler magic
rather than an actual value.  You see, it's impossible to create a 'C++
standard' without considering implementations.  If integer units had a NaN
(Not a Number) mapping from the start, we'd never have had NULL==0.
Testing for zero turns out to be easy to implement on most chips,
therefore that's what they settled on.

Theoretically, it should be possible to have a pointer which equals zero,
because *something* must exist at the base address, and with virtual
memory, segment selectors and the like, it's possible to have many places
where a pointer to it would equal zero.

Thus :

#define NULL ((void*)NaN)

Which on IA-64 would be perfectly acceptable (assuming I got the syntax
right :->)

Richard Cavell

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
....
> James Kuyper wrote:
> > If it isn't ==0, then it doesn't qualify as a null pointer constant.
> > If it doesn't have an integer type, it doesn't qualify as a null
> > pointer constant. And if it isn't a null pointer constant, it can't
> > be the value of NULL in a conforming implementation of C++.
>
> James is correct about the proper definition of 'NULL'.
>
> However, that does not mean an implementor can't choose whatever
> bit pattern it wants to represent a null pointer value.  If I'm

I've no disagreement with that statement. However, see below.

> not mistaken, IBM CICS uses a null pointer with the upper bit set,
> i.e.:
>
>     void *p = (void *)0x80000000;
>
>     if (p == NULL) ...    // true on CICS
>
> However, to be conforming, it must also allow comparisons of null
> pointers to zero:
>
>     p = 0;
>
>     if (p == 0) ...       // true always, everywhere
>
> Which means that 'NULL' must be defined as 0, regardless of the
> actual null pointer bit pattern.

Or as (1-1), or as 0L, or as '\0', or as 0x0, or as
__reserved_namespace::null_pointer_constant.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Richard John Cavell wrote:
....
> ...  You see, it's impossible to create a 'C++
> standard' without considering implementations. ...

There's nothing impossible about it. It's not even very difficult. A bad
idea, yes, but not difficult. Some people (not including me) have even
claimed that's exactly what actually happened. :-)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I understand that the standard of defining NULL to be zero is a choice given
to the programmer. A pointer when called will return an address to where its
value that it was initialized with is. Of course you probably know that. I
created a simple program using VC++6.0 to illustrate:

#include <stdio.h>
#include <iostream.h>

int gf_null(int* p_R)
{
 cout << "p_R: "<< p_R;
 return 1;
}

int main(int argc, char* argv[])
{
 int* p_R=0;
 return gf_null(NULL);

}

 the program returns
p_R: 0x00000000
I expanded the program to this:

int gf_null(int* p_R, int *p_S)
{
 cout << "p_S: "<< p_S << endl;
 cout << "p_R: "<< p_R << endl;
 return 1;
}

int main(int argc, char* argv[])
{
 int *p_S=0;
 int* p_R=0;
 return gf_null(NULL,NULL);

}

passing two NULL values and the output yeilds both of the 'same' registers.
p_R: 0x00000000
p_S: 0x00000000

If you were to use -1 for the value of the pointer then it returns two
'different' registers which the compiler uses for the two values. Although
both registers have the same value. So in fact NULL always ==0 if you use
most of the libraries for c/c++. Why would you want or need another value
for NULL if it is fine as 0.

If you are evaluating the NULL in an if statement and you use -1 you will
get the same results as if you used 0 so in the case of the if statement you
don't really need to have NULL ==0 you could have NULL ==-1.

The reason you would use 0 for NULL is to save mem thats about it because
whenever you initialize any pointers you need to set its value. Usually I
either set the pointers value to a class or char or whatever right away if I
need to use it right away if not then I just define it as NULL or 0 so that
the compilers happy.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ron Natalie <ron@sensor.com> writes:

|>  But your point is well taken, the standard makes no guarantees about
|>  how values are stored in memory, just their "value" when used in
|>  programs.

That's not quite true.  The C standard (and the C++ too, I believe)
guarantees that unsigned integral values be stored in pure binary
representation, and that the commun values between an unsigned type and
the corresponding signed type have the same representation.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Mark Williams wrote:
>
> > >
> > No.  0 will be all zeros.  There's also this quirky
> > -0 value (all ones), but that's almost always only generated as a
> result of
> > an operation, not a literal store.
> >
> > But your point is well taken, the standard makes no guarantees about
> how
> > values are stored in memory, just their "value" when used in programs.
>
> You appear to contradict yourself. You state that the value will be all
> zeros, and that the standard makes no guarantees about how the values
> are stored.
>
> Are you confirming, or denying that the value could in fact be all 1s?
> :-)
>

I don't contradict myself.  A ones complement zero is all ZEROS.
All ones is -0 (NEGATIVE ZERO).

The comment about no guarantees refers to implementations in general (one
can not make assumptions about the internal representations) not to the
ones complement example.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

wmm@fastdial.net wrote:
> The second was that absolute location 0 was not a
> useful location in the hardware and/or operating system
> on which C originally ran.

Actually the latter statement is untrue.  The PDP-11 UNIX that
was the early C platform had the first instruction of the executed
program at location zero.  Later versions that used the split
instruction and data space feature of some of the processors
had to consiously avoid putting anything at data location zero
to avoid running afoul of the zero pointer value.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

kanze@gabi-soft.de wrote:
>
> Ron Natalie <ron@sensor.com> writes:
>
> |>  But your point is well taken, the standard makes no guarantees about
> |>  how values are stored in memory, just their "value" when used in
> |>  programs.
>
> That's not quite true.  The C standard (and the C++ too, I believe)
> guarantees that unsigned integral values be stored in pure binary
> representation, and that the commun values between an unsigned type and
> the corresponding signed type have the same representation.
>

No the specs don't say that.  It says that unsigned numbers obey modulo 2**number
of bits math.  It says that the non-negative values share the same representation.
A ones-complement or sign-bit type encoding would be perfectly acceptible with
a straight binary representation.

Furthermore, the standard still doesn't say anything about the representation, just
the behavior of the math.  If I had a machine where all the integral values were stored
as their bit-complement, it would still meet the letter of the standard.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Tue, 4 Jul 2000 05:11:56 CST, Ron Natalie <ron@sensor.com> wrote:

>
>
>kanze@gabi-soft.de wrote:
>>
>> Ron Natalie <ron@sensor.com> writes:
>>
>> That's not quite true.  The C standard (and the C++ too, I believe)
>> guarantees that unsigned integral values be stored in pure binary
>> representation, and that the commun values between an unsigned type and
>> the corresponding signed type have the same representation.
>>
>
>No the specs don't say that

Section 3.9.1 paragraph 7 requires the use of a pure binary system in
the representation of integer types.
---
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Richard John Cavell <rjcavell@student.unimelb.edu.au> writes:
>> Well, I'm suggesting that the NULL==0 convention exists because of
>> the Z flag bit that happens to exist in just about every processor.
>> It has everything to do with 'testing for zero'.  #define NULL 0
>> gives the whole game away.

Keith Thompson wrote:
> In the very early days of C (before K&R1), I suspect that all C
> implementations used all-bits-zero as the representation of a null
> pointer -- and you could meaningfully use a non-zero integer literal
> as a pointer value if you happened to know the machine address of,
> say, an I/O register.  That's why we still have the convention of
> using a literal 0 as a null pointer constant, a convention that C++
> inherited directly from C.

I think more to the point was that the early PDP-11 C compilers
allowed pointer/integer conversions and comparisons without the
need for explicit typecasts.  In those days, pointers and ints
were also assumed to be same size.

Of course, that was 30 years ago (20 years before ANSI C).

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ron Natalie wrote:
>> I don't need to search, the C++ standard is quite clear on it,
>> [NULL] must be an INTEGERAL constant expression.
>>
>> In C it can be (void*)0, but in C++ not only is this not allowed, it
>> won't work.

David R Tribble <david@tribble.com> wrote:
>> Which is annoying.  Several of us have proposed that '((void*)0)' be
>> treated as a special case with the semantic meaning of "null pointer
>> constant".  (Apparently, some compilers actually do this.)
>>
>> The proposal would allow an implementation to define 'NULL' to
>> '((void*)0)' for both C and C++.  It would also get rid of some of
>> the typing ambiguities when using 'NULL' in C++.
>>
>> Most of the arguments against this proposal are typically "what's
>> wrong with 0?".  The other objection is "but this will break too
>> much exsting code", but none of us are proposing getting rid of 0 as
>> the "other" null pointer constant.

wmm@fastdial.net wrote:
> The arguments against this that I've heard are that it breaks the
> type system.  In C, the initializations of both p1 and p2 are
> permitted:
>
>         void * voidp;
>         int* p1 = (void*) 0;
>         int* p2 = voidp;
>
> The reason is that a void* is compatible with a typed pointer in
> C.  That is not the case in C++.  Your proposal would make the
> p1 initialization valid.  You're then faced with what to do about
> the p2 initialization.

Nothing about the assignment to p2 would change.  My words were
"treat '((void*)0)' as a special case", meaning that everything else
about pointers, null or otherwise, would be the same.

> If you make it valid, too, then you've
> lost type-safety for pointers.  If you leave it invalid, you
> are making the decision on compatibility no longer based solely
> on the type as in current C++ but on other criteria as well (is
> it a constant expression, and if so, is the value 0?).

voidp is not a constant expression, so nothing about its use would
change.

Rewriting your example may clarify what I'm driving at:

    #define NULL  ((void *) 0)

    int *   p1 = NULL;   // Okay

I (and others) simply want 'NULL' to be something a little more
typesafe than 0.  '((void*)0)' seems like a logical choice, since
it's used quite successfully in C.  However, it would require
allowing C++ to treat it as a special semantic case because of the
existing rules about casting void pointers to other types, which
we don't want to change.

> Many of
> us prefer the inconvenience of the current null pointer constant
> definition to this kind of kludginess and inconsistency in
> handling type compatibility.

Some of us believe that C++ can be modified to have the best of
both worlds without ugliness.  Some of us prefer to use the name
'NULL' or 'null' when we mean "null pointer" instead of '0'.

> I would be much more inclined to support a built-in keyword for
> null pointers than to change the type semantics to allow
> (void*)0 to be compatible with typed pointers.

The choices suggested so far have been:

1. A 'null' keyword.
2. A standard 'null' constant with the proper type behavior.
3. A definition of 'NULL' with the proper type behavior.

I'd take any of them.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi !

Richard John Cavell wrote:
>
> >       The fact that the null pointer constant is reperesented in program
> > source code by literal "0" (or by integral constant expression, that
> > evaluates to zero) has nothing to do with "testing for zero" in compiled
> > code.
>
> Well, I'm suggesting that the NULL==0 convention exists because of the Z
> flag bit that happens to exist in just about every processor.  It has
> everything to do with 'testing for zero'.  #define NULL 0 gives the whole
> game away.

 No, it doesn't. I believe that you are overestimating the dependency
between the literal representation of null pointer constant (NPC) in
program source and null pointer value (NPV) in compiled code.
 For integer types in modern two's-complementary-represenation based
machines the bond between the two is obvious: initializing an integer
variable with zero results in zeroing all bits of memory occupied by the
variable. For floating point types and pointers it is not neccessarily
true.
 In the following cases:

 int i = 0;
 float f = 0;
 void* p = 0;

 the compiler's resonsibility is to recognize the fact that literal '0'
is used in three different contexts (integer, floating point and
pointer) and generate the correct code for each particular case, which
will initialize each varible's memory with corresponding bit pattern
(possibly _different_ for each variable).
 There is absolutely no requrement that memory occupied by variable 'p'
is initialized with "all-zeroes" bit patern. But it is requred that it
is initialized with NPV of 'void*' type. Which, BTW, can be represented
by any bit pattern suitable for given platform.

> > Compiled code is free to use just _any_ physical value for null
> > pointers, whatever is most appropriate for given platform:
>
> If I went into my current job's source code and changed it to read #define
> NULL 27, I'm quite sure it wouldn't compile.  Does this mean Visual C++ is
> not standards-compliant?  No.

 Zero in pointer context is recognized as NPC by the compiler. '27' is
not. That's the only reason why it wouldn't compile.

> > zero, NAN, -1 etc. "Zero" is just a portable (and rather confusing)
> > way to represent this value in C/C++ programs.
>
> If the Not-A-Thing bit were commonplace amongst processors, and there were
> a flag to represent the condition that the last value created was NAT
> (just like the Z flag represents ==0), would it be sensible to change the
> standard?  I think so.  Zero does not mean nothing.  It is the integer
> between -1 and 1.

 Zero in pointer context in _more_ then an integer. It is null pointer
constant. As long as pointer and integer contexts can be unambiquously
distinguished, there is no reason to replace zero as NPC with anythig
else. Unfortunately there are cases when these contexts cannot be
distinguished (overloaded functions, for instance).

> Perhaps part of the problem is that pointers are always numbers, usually
> held in the same registers that integer data is stored in, and often of
> the same bit length as the sizeof(int) for that platform. Thus pointer
> arithmetic is intuitive.  If pointers were given names, like "56 Wentworth
> Way", or "Derek", we'd never have any cognitive dissonance over what zero
> means.
>
> Richard Cavell

Best regards,
Andrey.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

wmm@fastdial.net writes:

|>  In my opinion, C++ is more consistent as a result of saying that any
|>  expression of type "void*" is incompatible with a typed pointer.

More consistent than what?  We also say that an expression of type int
is incompatible with a typed pointer.  (Unless, of course, it happens to
be a constant expression which evaluates to 0.)

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ron Natalie <ron@sensor.com> wrote:
>
>
>wmm@fastdial.net wrote:
>> The second was that absolute location 0 was not a
>> useful location in the hardware and/or operating system
>> on which C originally ran.
>
>Actually the latter statement is untrue.  The PDP-11 UNIX that
>was the early C platform had the first instruction of the
executed
>program at location zero.

I would consider that "not useful" -- there's no reason a
non-null pointer would ever point to that location.

>Later versions that used the split
>instruction and data space feature of some of the processors
>had to consiously avoid putting anything at data location zero
>to avoid running afoul of the zero pointer value.

That's one way of dealing with the problem -- making location
0 a reserved address allows you to keep the all-bits-zero
runtime value.  When the value of the null pointer was being
discussed at Stratus, it was pointed out that often null
pointers are used to access members of structures, so the
effective address isn't the null pointer value itself but
rather the null pointer value plus some (usually small) offset.
Since the goal was to make both read and write accesses using
the null pointer generate a hardware fault, that meant a range
of addresses needed to be dedicated.  That wasn't practical
using absolute location 0 in our architecture because the 68000
processor makes zero-page references especially efficient, so
various data used in time-critical operations were placed
there.  That's why the null pointer value was placed way high
in the address space, to allow a whole page to catch "null
plus offset" dereferences without using up the valuable resource
of page 0.

-- William M. Miller



-----------------------------------------------------------

Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"William M. Miller" <wmmNOwmSPAM@fastdial.net.invalid> wrote:
>
> Ron Natalie <ron@sensor.com> wrote:
> >Actually the latter statement is untrue.  The PDP-11 UNIX that
> >was the early C platform had the first instruction of the
> executed
> >program at location zero.
>
> I would consider that "not useful" -- there's no reason a
> non-null pointer would ever point to that location.

Not useful? There are platforms out there where have address 0 holds
important information.


> That's one way of dealing with the problem -- making location
> 0 a reserved address allows you to keep the all-bits-zero
> runtime value.

That now excludes such systems from having ANSI C/C++.


>  When the value of the null pointer was being
> discussed at Stratus, it was pointed out that often null
> pointers are used to access members of structures, so the
> effective address isn't the null pointer value itself but
> rather the null pointer value plus some (usually small) offset.
> Since the goal was to make both read and write accesses using
> the null pointer generate a hardware fault, that meant a range
> of addresses needed to be dedicated.  That wasn't practical
> using absolute location 0 in our architecture because the 68000
> processor makes zero-page references especially efficient, so
> various data used in time-critical operations were placed
> there.  That's why the null pointer value was placed way high
> in the address space, to allow a whole page to catch "null
> plus offset" dereferences without using up the valuable resource
> of page 0.

You have condradicted yourself by describing a reason why a non-null
pointer would point at address 0.

Paul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"William M. Miller" wrote:
>
> Ron Natalie <ron@sensor.com> wrote:
> >
> >
> >wmm@fastdial.net wrote:
> >> The second was that absolute location 0 was not a
> >> useful location in the hardware and/or operating system
> >> on which C originally ran.
> >
> >Actually the latter statement is untrue.  The PDP-11 UNIX that
> >was the early C platform had the first instruction of the
> executed
> >program at location zero.
>
> I would consider that "not useful" -- there's no reason a
> non-null pointer would ever point to that location.

Why not? Depending upon the implementation, a function pointer of the
correct (implementation-defined) type, initialized with all bits zero,
might represent a validly executable function on such a platform, one
which has the effect of restarting the program from scratch. A dangerous
technique, to be sure, and not one for use in portable code, but not all
code needs to be portable.

Even more dangerous, and even less portable, would be the assignment of
that address to a data pointer, which could then be used to implement
self-modifying code. This should only be done by someone who's an
absolute expert on the memory layout of that particular implementation.
I'd certainly never try it! However, in certain environments which are
extremely low on memory, self-modifying code might be a legitimate
technique. Slightly more legitimate would be code that computes a
checksum of itself.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Black wrote:
>
> "William M. Miller" <wmmNOwmSPAM@fastdial.net.invalid> wrote:
> >
> > Ron Natalie <ron@sensor.com> wrote:
> > >Actually the latter statement is untrue.  The PDP-11 UNIX that
> > >was the early C platform had the first instruction of the
> > executed
> > >program at location zero.
> >
> > I would consider that "not useful" -- there's no reason a
> > non-null pointer would ever point to that location.
>
> Not useful? There are platforms out there where have address 0 holds
> important information.

For example, on the x86 real mode, interrupt table has address 0.
The following program will (in the correct memory model) print
out the interrupt table:

int main()
{
  void** int_table = 0;
  for (int i = 0; i < 256; ++i)
    cout << i << ": " << int_table[i] << endl;
}

Of course, bugs that cause writing to a null pointer can have
interesting effects... ;-)

>
> > That's one way of dealing with the problem -- making location
> > 0 a reserved address allows you to keep the all-bits-zero
> > runtime value.
>
> That now excludes such systems from having ANSI C/C++.

Why?

>
> >  When the value of the null pointer was being
> > discussed at Stratus, it was pointed out that often null
> > pointers are used to access members of structures, so the
> > effective address isn't the null pointer value itself but
> > rather the null pointer value plus some (usually small) offset.
> > Since the goal was to make both read and write accesses using
> > the null pointer generate a hardware fault, that meant a range
> > of addresses needed to be dedicated.  That wasn't practical
> > using absolute location 0 in our architecture because the 68000
> > processor makes zero-page references especially efficient, so
> > various data used in time-critical operations were placed
> > there.  That's why the null pointer value was placed way high
> > in the address space, to allow a whole page to catch "null
> > plus offset" dereferences without using up the valuable resource
> > of page 0.
>
> You have condradicted yourself by describing a reason why a non-null
> pointer would point at address 0.

But on that implementation, a pointer having address 0 is not
a null pointer. Therefore I cannot see a contradiction here.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Stephen Clamage wrote:
>
> On Tue, 4 Jul 2000 05:11:56 CST, Ron Natalie <ron@sensor.com> wrote:
>
> >
> >
> >kanze@gabi-soft.de wrote:
> >>
> >> Ron Natalie <ron@sensor.com> writes:
> >>
> >> That's not quite true.  The C standard (and the C++ too, I believe)
> >> guarantees that unsigned integral values be stored in pure binary
> >> representation, and that the commun values between an unsigned type and
> >> the corresponding signed type have the same representation.
> >>
> >
> >No the specs don't say that
>
> Section 3.9.1 paragraph 7 requires the use of a pure binary system in
> the representation of integer types.

But there's the as-if rule. That is, as long as no conforming
program can tell (i.e. bit operations work as if a binary
representation were used), the implementation can use any
representation it wants.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
>
> Paul Black wrote:
> >
> > "William M. Miller" <wmmNOwmSPAM@fastdial.net.invalid> wrote:
> > > I would consider that "not useful" -- there's no reason a
> > > non-null pointer would ever point to that location.
> >
> > Not useful? There are platforms out there where have address 0 holds
> > important information.

That was a great sentence I wrote!


> For example, on the x86 real mode, interrupt table has address 0.
> The following program will (in the correct memory model) print
> out the interrupt table:
>
> int main()
> {
>   void** int_table = 0;
>   for (int i = 0; i < 256; ++i)
>     cout << i << ": " << int_table[i] << endl;
> }
>
> Of course, bugs that cause writing to a null pointer can have
> interesting effects... ;-)

int_table is a null pointer, there is no guarantee that it points to
location 0.



> > > That's one way of dealing with the problem -- making location
> > > 0 a reserved address allows you to keep the all-bits-zero
> > > runtime value.
> >
> > That now excludes such systems from having ANSI C/C++.
>
> Why?

Because in such systems location 0 holds something useful, it can't be
used be used for both a null pointer and a valid location. It's either
one or the other.



> > >  When the value of the null pointer was being
> > > discussed at Stratus, it was pointed out that often null
> > > pointers are used to access members of structures, so the
> > > effective address isn't the null pointer value itself but
> > > rather the null pointer value plus some (usually small) offset.
> > > Since the goal was to make both read and write accesses using
> > > the null pointer generate a hardware fault, that meant a range
> > > of addresses needed to be dedicated.  That wasn't practical
> > > using absolute location 0 in our architecture because the 68000
> > > processor makes zero-page references especially efficient, so
> > > various data used in time-critical operations were placed
> > > there.  That's why the null pointer value was placed way high
> > > in the address space, to allow a whole page to catch "null
> > > plus offset" dereferences without using up the valuable resource
> > > of page 0.
> >
> > You have condradicted yourself by describing a reason why a non-null
> > pointer would point at address 0.
>
> But on that implementation, a pointer having address 0 is not
> a null pointer. Therefore I cannot see a contradiction here.

This is what the OP said: "there's no reason a non-null pointer would
ever point to that location." The contradiction is that in the case
described above, the pointer is non-null and points at location 0.

Paul

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Black <paul.black@oxsemi.com> writes:
> This is what the OP said: "there's no reason a non-null pointer would
> ever point to that location." The contradiction is that in the case
> described above, the pointer is non-null and points at location 0.

All that's required in this case is for the implementation to define
dereferencing of a null pointer as accessing the object at location 0
in memory. Code that needs to worry about null pointers continues to
check for == 0, and code that intends to access the object at address
0 goes ahead and just does it.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Black <paul.black@oxsemi.com> wrote:

> Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> >=20
> > Paul Black wrote:
> > >
> > > "William M. Miller" <wmmNOwmSPAM@fastdial.net.invalid> wrote:

> > > > That's one way of dealing with the problem -- making location
> > > > 0 a reserved address allows you to keep the all-bits-zero
> > > > runtime value.
> > >
> > > That now excludes such systems from having ANSI C/C++.
> >=20
> > Why?
>=20
> Because in such systems location 0 holds something useful, it can't be
> used be used for both a null pointer and a valid location. It's either
> one or the other.

But William was explicitly talking about a system where memory location
0 did not hold useful information.

OTOH, it is perfectly possible to use the address of something useful as
a null pointer constant. Dereferencing null pointers is undefined. An
implementation may produce crashes, but it is not required to do so. On
the contrary: The implementation may define the result of dereferencing
a null pointer (e.g. as accessing memory location 0).

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

A null pointer value just may not be the address of a _C++_ object.=20

[SNIP Mr Millers discussion of address 0 on 68000 and how it led to the
choice of a non-zero null pointer value].

> > > You have condradicted yourself by describing a reason why a non-nul=
l
> > > pointer would point at address 0.
> >=20
> > But on that implementation, a pointer having address 0 is not
> > a null pointer. Therefore I cannot see a contradiction here.
>=20
> This is what the OP said: "there's no reason a non-null pointer would
> ever point to that location." The contradiction is that in the case
> described above, the pointer is non-null and points at location 0.

That was talking about a different system.=20

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Regards, J=F6rg

--=20
J=F6rg Barfurth                         joerg.barfurth@attglobal.net
-------------- using std::disclaimer; -----------------------------
Download StarOffice 5.2 at            http://www.sun.com/staroffice
Runs on Solaris - Linux - Windows

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <395802F8.CFF6D3F3@wizard.net>, James Kuyper
> <kuyper@wizard.net> writes
> >NULL is "a" null pointer constant (NPC), not "the" NPC. There are a
> >practical infinity of NPCs, including 0, (1-1), (2-2), (1+2-3), (2*2-4),
> >(3/2-1), etc.
>
> No, those are just different ways of writing it:)

An NPC is defined as an expression, not a value. All NPCs compare equal,
but that doesn't mean that they're all the same thing. They're certainly
not all interchangeable. For one thing, they give different results when
stringized using the # operator :-).

They're also different in more important ways. Some NPCs have associated
namespaces, with consequences under Koenig lookup. Different NPCs have
different types, with different consequences under default promotions,
and possibly causing templates to be instantiated with different
arguments. Those differences don't matter when an NPC is used as NULL is
intended to be used, as a value to be converted to a pointer. However,
the standard doesn't require that NULL be used only in that fashion.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ron Natalie wrote:
> I don't need to search, the C++ standard is quite clear on it, [NULL]
> must be an INTEGERAL constant expression.
>
> In C it can be (void*)0, but in C++ not only is this not allowed, it
> won't work.

Which is annoying.  Several of us have proposed that '((void*)0)' be
treated as a special case with the semantic meaning of "null pointer
constant".  (Apparently, some compilers actually do this.)

The proposal would allow an implementation to define 'NULL' to
'((void*)0)' for both C and C++.  It would also get rid of some of
the typing ambiguities when using 'NULL' in C++.

Most of the arguments against this proposal are typically "what's
wrong with 0?".  The other objection is "but this will break too
much exsting code", but none of us are proposing getting rid of 0 as
the "other" null pointer constant.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi !

James Kuyper wrote:
> ...
> A null pointer constant is an expression with an integer type, and value
> zero. So if NULL is stored in an integer variable of any type, the
> ...

 This particular statement is not correct. A null pointer constant is an
_interger_ _constant_ _expression_ that evaluates to zero. Just any
integer expression won't do.

Best regards,
Andrey.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <395B73AB.E1BC0DFD@tribble.com>,
  David R Tribble <david@tribble.com> wrote:
> Ron Natalie wrote:
> > I don't need to search, the C++ standard is quite clear on it,
[NULL]
> > must be an INTEGERAL constant expression.
> >
> > In C it can be (void*)0, but in C++ not only is this not allowed, it
> > won't work.
>
> Which is annoying.  Several of us have proposed that '((void*)0)' be
> treated as a special case with the semantic meaning of "null pointer
> constant".  (Apparently, some compilers actually do this.)
>
> The proposal would allow an implementation to define 'NULL' to
> '((void*)0)' for both C and C++.  It would also get rid of some of
> the typing ambiguities when using 'NULL' in C++.
>
> Most of the arguments against this proposal are typically "what's
> wrong with 0?".  The other objection is "but this will break too
> much exsting code", but none of us are proposing getting rid of 0 as
> the "other" null pointer constant.

The arguments against this that I've heard are that it breaks the
type system.  In C, the initializations of both p1 and p2 are
permitted:

        void * voidp;
        int* p1 = (void*) 0;
        int* p2 = voidp;

The reason is that a void* is compatible with a typed pointer in
C.  That is not the case in C++.  Your proposal would make the
p1 initialization valid.  You're then faced with what to do about
the p2 initialization.  If you make it valid, too, then you've
lost type-safety for pointers.  If you leave it invalid, you
are making the decision on compatibility no longer based solely
on the type as in current C++ but on other criteria as well (is
it a constant expression, and if so, is the value 0?).  Many of
us prefer the inconvenience of the current null pointer constant
definition to this kind of kludginess and inconsistency in
handling type compatibility.

I would be much more inclined to support a built-in keyword for
null pointers than to change the type semantics to allow
(void*)0 to be compatible with typed pointers.
--
William M. Miller, wmm@fastdial.net
OnDisplay, Inc. (www.ondisplay.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi !

Richard John Cavell wrote:
> ...
> Well, I guess that's what I'm proposing - that NULL be compiler magic
> rather than an actual value.  You see, it's impossible to create a 'C++
> standard' without considering implementations.  If integer units had a NaN
> (Not a Number) mapping from the start, we'd never have had NULL==0.
> Testing for zero turns out to be easy to implement on most chips,
> therefore that's what they settled on.
>
> Theoretically, it should be possible to have a pointer which equals zero,
> because *something* must exist at the base address, and with virtual
> memory, segment selectors and the like, it's possible to have many places
> where a pointer to it would equal zero.
>
> Thus :
>
> #define NULL ((void*)NaN)
>
> Which on IA-64 would be perfectly acceptable (assuming I got the syntax
> right :->)
>

 The fact that the null pointer constant is reperesented in program
source code by literal "0" (or by integral constant expression, that
evaluates to zero) has nothing to do with "testing for zero" in compiled
code. Compiled code is free to use just _any_ physical value for null
pointers, whatever is most appropriate for given platform: zero, NAN, -1
etc. "Zero" is just a portable (and rather confusing) way to represent
this value in C/C++ programs.

Best regatds,
Andrey.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

<wmm@fastdial.net> wrote

[My liberal edits in square brackets]

> [ somebody proposed that the next line should be valid ]
>         int* p1 = (void*) 0;
> you are making the decision on compatibility [not] based solely
> on the type [...] but on other criteria as well (is
> it a constant expression, and if so, is the value 0?).  [this proposal
has] kludginess
> and inconsistency in handling type compatibility.

Now if someone were to propose making this line valid:
      int* p1 = (int) 0;
you could write exactly the same thing.  On the other hand you might just
tell them that it is already valid.

When defending the status quo  be careful when attacking proposals that are
type-unsafe.  The status quo is type-unsafe.

> I would be much more inclined to support a built-in keyword for null
pointers ...

Agreed.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrey Tarasevich wrote:
>
> Hi !
>
> James Kuyper wrote:
> > ...
> > A null pointer constant is an expression with an integer type, and value
> > zero. So if NULL is stored in an integer variable of any type, the
> > ...
>
>         This particular statement is not correct. A null pointer constant is an
> _interger_ _constant_ _expression_ that evaluates to zero. Just any
> integer expression won't do.

Yes. An NPC is an integer constant expression. It's also an expression
with integer type. It's also an expression. All three statements are
true. My statement wasn't meant as a definition, nor was it worded as
one. It's a true statement about null pointer constants, that included
all the characteristics I needed to make my point, and only those
characteristics. The fact that there's a more specific statement that
would also be true doesn't make it false. I've quoted the definition in
full or in part in several different places in this thread, and I'm
getting tired of having to repeat myself.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8jge2m$ug9$1@nnrp1.deja.com>, wmm@fastdial.net wrote:

> The arguments against this that I've heard are that it breaks the
> type system.  In C, the initializations of both p1 and p2 are
> permitted:
>
>         void * voidp;
>         int* p1 = (void*) 0;
>         int* p2 = voidp;
>
> The reason is that a void* is compatible with a typed pointer in
> C.  That is not the case in C++.  Your proposal would make the
> p1 initialization valid.  You're then faced with what to do about
> the p2 initialization.  If you make it valid, too, then you've
> lost type-safety for pointers.  If you leave it invalid, you
> are making the decision on compatibility no longer based solely
> on the type as in current C++ but on other criteria as well (is
> it a constant expression, and if so, is the value 0?).
  ***************************************************

C++ has to do that anyway to make p1 = 0 legal and p1 = (0,0) illegal.

>                                                         Many of
> us prefer the inconvenience of the current null pointer constant
> definition to this kind of kludginess and inconsistency in
> handling type compatibility.

But this argument is completely faulty.

Both in C and in C++ the rules for assigning to a pointer p = <expr> are:

Is the expression on the right hand a pointer that may be assigned to p?
Then the assignment is legal. Otherwise, is the expression on the right
hand a "null pointer constant"? Then the assignment is legal and assigns a
null pointer of the correct type. In all other cases the assignment is
illegal.

The only difference is the rule what a "null pointer constant" is.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Sat, 1 Jul 2000, Andrey Tarasevich wrote:

>  The fact that the null pointer constant is reperesented in program
> source code by literal "0" (or by integral constant expression, that
> evaluates to zero) has nothing to do with "testing for zero" in compiled
> code.

Well, I'm suggesting that the NULL==0 convention exists because of the Z
flag bit that happens to exist in just about every processor.  It has
everything to do with 'testing for zero'.  #define NULL 0 gives the whole
game away.

> Compiled code is free to use just _any_ physical value for null
> pointers, whatever is most appropriate for given platform:

If I went into my current job's source code and changed it to read #define
NULL 27, I'm quite sure it wouldn't compile.  Does this mean Visual C++ is
not standards-compliant?  No.

> zero, NAN, -1 etc. "Zero" is just a portable (and rather confusing)
> way to represent this value in C/C++ programs.

If the Not-A-Thing bit were commonplace amongst processors, and there were
a flag to represent the condition that the last value created was NAT
(just like the Z flag represents ==0), would it be sensible to change the
standard?  I think so.  Zero does not mean nothing.  It is the integer
between -1 and 1.

Perhaps part of the problem is that pointers are always numbers, usually
held in the same registers that integer data is stored in, and often of
the same bit length as the sizeof(int) for that platform. Thus pointer
arithmetic is intuitive.  If pointers were given names, like "56 Wentworth
Way", or "Derek", we'd never have any cognitive dissonance over what zero
means.

Richard Cavell

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <christian.bau-3006000939180001@christian-
mac.isltd.insignia.com>,
  christian.bau@isltd.insignia.com (Christian Bau) wrote:
> In article <8jge2m$ug9$1@nnrp1.deja.com>, wmm@fastdial.net wrote:
>
> > The arguments against this that I've heard are that it breaks the
> > type system.  In C, the initializations of both p1 and p2 are
> > permitted:
> >
> >         void * voidp;
> >         int* p1 = (void*) 0;
> >         int* p2 = voidp;
> >
> > The reason is that a void* is compatible with a typed pointer in
> > C.  That is not the case in C++.  Your proposal would make the
> > p1 initialization valid.  You're then faced with what to do about
> > the p2 initialization.  If you make it valid, too, then you've
> > lost type-safety for pointers.  If you leave it invalid, you
> > are making the decision on compatibility no longer based solely
> > on the type as in current C++ but on other criteria as well (is
> > it a constant expression, and if so, is the value 0?).
>   ***************************************************
>
> C++ has to do that anyway to make p1 = 0 legal and p1 = (0,0) illegal.
>
> >                                                         Many of
> > us prefer the inconvenience of the current null pointer constant
> > definition to this kind of kludginess and inconsistency in
> > handling type compatibility.
>
> But this argument is completely faulty.
>
> Both in C and in C++ the rules for assigning to a pointer p = <expr>
are:
>
> Is the expression on the right hand a pointer that may be assigned to
p?
> Then the assignment is legal. Otherwise, is the expression on the
right
> hand a "null pointer constant"? Then the assignment is legal and
assigns a
> null pointer of the correct type. In all other cases the assignment is
> illegal.
>
> The only difference is the rule what a "null pointer constant" is.

You're entitled to your opinion.

In my opinion, C++ is more consistent as a result of saying
that any expression of type "void*" is incompatible with a
typed pointer.

I'm not defending the use of 0 as the null pointer constant.
That came from the earliest days of C when not as much attention
was given to type safety and such, and there's just too much
legacy code that depends on this convention.  The fact that we
have to do these kinds of tricks in deciding whether an integer
expression is compatible with a pointer does not make extending
the realm of such trickery into pointer-pointer compatibility
more attractive to me.

--
William M. Miller, wmm@fastdial.net
OnDisplay, Inc. (www.ondisplay.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jim Dziedzic wrote:
>
> I understand that the standard of defining NULL to be zero is a choice given
> to the programmer. ...

You understand incorrectly. Defining NULL is something an implementation
does, not the programmer.

....
> both registers have the same value. So in fact NULL always ==0 if you use
> most of the libraries for c/c++. Why would you want or need another value
> for NULL if it is fine as 0.

I have no idea. Nonetheless, the standard does allow other
possibilities. For instance:

namespace __reserved_namespace]
{
struct __NULL_class
{
 static unsigned long __NPC=0;
};
}
#define NULL __reserved_namespace::__NULL_class::__NPC

Imagine that __reserved_namespace and __NULL_class have all sort of
interesting functions with names identical to standard library
functions. Imagine the fun when Koenig lookup leads to one of those
functions being used instead of an unqualified standard library function
call. Fun!

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3957A44C.90652CCC@sensor.com>,
  Ron Natalie <ron@sensor.com> wrote:
>
>
> Mark Williams wrote:
> >
> > In article <3956AE1E.ADEDBFB2@wizard.net>,
> >   James Kuyper <kuyper@wizard.net> wrote:
> > >
> > > A null pointer constant is an expression with an integer type, and
> > value
> > > zero. So if NULL is stored in an integer variable of any type, the
> > > conversion is well-defined (value preserving), and all of the
value
> > bits
> > > of that variable WILL be 0.
> >
> > Is that really true? On a 1-s complement machine, couldnt the value
bits
> > all be 1?
> >
> No.  0 will be all zeros.  There's also this quirky
> -0 value (all ones), but that's almost always only generated as a
result of
> an operation, not a literal store.
>
> But your point is well taken, the standard makes no guarantees about
how
> values are stored in memory, just their "value" when used in programs.

You appear to contradict yourself. You state that the value will be all
zeros, and that the standard makes no guarantees about how the values
are stored.

Are you confirming, or denying that the value could in fact be all 1s?
:-)

(I am not asking about the behavior of specific 1s complement machines)
-------------
Mark Williams


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <Pine.OSF.4.10.10007020343300.3865-
100000@cassius.its.unimelb.edu.au>,
  Richard John Cavell <rjcavell@student.unimelb.edu.au> wrote:
> On Sat, 1 Jul 2000, Andrey Tarasevich wrote:
>
> >  The fact that the null pointer constant is reperesented in
program
> > source code by literal "0" (or by integral constant expression, that
> > evaluates to zero) has nothing to do with "testing for zero" in
compiled
> > code.
>
> Well, I'm suggesting that the NULL==0 convention exists because of
the Z
> flag bit that happens to exist in just about every processor.  It has
> everything to do with 'testing for zero'.  #define NULL 0 gives the
whole
> game away.

There are two factors behind the choice of 0 as the null
pointer constant, in terms of the deep dark history of C.
One is, as you said, that it's easy to test for 0, at least
on the processors targeted by the original implementation
of C.  The second was that absolute location 0 was not a
useful location in the hardware and/or operating system
on which C originally ran.

As C implementations proliferated, however, the second
criterion was not valid on some systems -- that is, absolute
location 0 actually did have a use.  Standard C and C++
accommodate this fact by mandating only the source form of
a null pointer constant; the runtime representation of a
null pointer can be anything desired.  (My recollection is
hazy, but I believe that the null pointer on a Stratus VOS
system was represented by the bit pattern 0xffff0000, which
had the useful feature that either a read or write of that
address would cause a hardware fault.  The bit pattern of
all bits zero was rejected because it was legitimately
readable and so could not be caused to fault on a read.  This
consideration outweighed the ease of testing for zero.  Of
course, the source representation of a null pointer constant
was still 0.  It was the compiler's job to translate the
source representation, 0, into the runtime bit pattern,
0xffff0000.)

> > Compiled code is free to use just _any_ physical value for null
> > pointers, whatever is most appropriate for given platform:
>
> If I went into my current job's source code and changed it to read
#define
> NULL 27, I'm quite sure it wouldn't compile.  Does this mean Visual
C++ is
> not standards-compliant?  No.

You're missing the point.  The value of NULL is the source
representation, not the runtime representation.  The source
representation of the null pointer constant must be 0 (or some
other integral constant expression that evaluates to 0).  It's
the runtime representation that can be anything, and there's
nothing you can do at source level to control that, it's part
of the implementation.

To go back to my VOS example above, the following code will
illustrate the difference:

    bool f() {
        union {
            int i;
            void* p;
        } u;
        u.p = 0;    // makes p a null pointer
        return u.i == 0xffff0000;
    }

This function will return the value "true" on Stratus VOS (if
my memory of the details of that implementation is correct,
otherwise we can treat it as hypothetical but reasonable),
and this implementation is perfectly conforming.  The null
pointer constant is a 0-valued integral constant expression,
but the actual bit pattern of a null pointer can be anything.

I hope this helps clear up the confusion.

--
William M. Miller, wmm@fastdial.net
OnDisplay, Inc. (www.ondisplay.com)


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Richard John Cavell <rjcavell@student.unimelb.edu.au> writes:
[...]
> Well, I'm suggesting that the NULL==0 convention exists because of the Z
> flag bit that happens to exist in just about every processor.  It has
> everything to do with 'testing for zero'.  #define NULL 0 gives the whole
> game away.

In the very early days of C (before K&R1), I suspect that all C
implementations used all-bits-zero as the representation of a null
pointer -- and you could meaningfully use a non-zero integer literal
as a pointer value if you happened to know the machine address of,
say, an I/O register.  That's why we still have the convention of
using a literal 0 as a null pointer constant, a convention that C++
inherited directly from C.

These assumptions are no longer valid, and haven't been for at least
20 years.  There are real-world C and C++ implementations in which
null pointers are *not* represented as all-bits-zero.  Our continued
use of 0 to represent a null pointer constant is the result of decades
of backward compatibility.  A great deal of effort was expended to
define the C and C++ languages so that a literal 0 is a null pointer
constant *and* a null pointer needn't be represented by all-bits-zero.
The current situation is confusing (as you can see by the length of
this thread), but it's about the best that could be done given the
almost contradictory requirements.

I'm not certain about all the historical details, particularly the
exact timing.  For example, I don't know which came first, a C
language definition that didn't require a null pointer to be
all-bits-zero, or an implementation that actually had a non-zero null
pointer.  This had all stabilized in its current form before C++ was
created.

> Perhaps part of the problem is that pointers are always numbers, usually
> held in the same registers that integer data is stored in, and often of
> the same bit length as the sizeof(int) for that platform. Thus pointer
> arithmetic is intuitive.  If pointers were given names, like "56 Wentworth
> Way", or "Derek", we'd never have any cognitive dissonance over what zero
> means.

Don't assume that pointers are always numbers; they're not.  Pointers
are pointers, integers are integers, and pointer arithmetic is not
defined the same way as integer arithmetic.  On one of the machines I
work on, the Cray T90, a character pointer is a 64-bit word pointer
with a byte offset in the high-order bits.  Arithmetic on a char* has
to take those bits into account.  Other systems have even more exotic
representations.

This is covered in some detail in the C FAQ at
<http://www.eskimo.com/~scs/C-faq/top.html>.  I couldn't find similar
information in the C++ FAQ, but I believe the C++ semantics in this
area are identical to C, or nearly so.

--
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,

NULL is often used to return an 'invalid' output, particularly with
pointers.  NULL generally equals zero.

Is there any example of an implementation where NULL has not equalled
zero?

Can I always do:

if (!pClass)
{//error}

where pClass==NULL indicates an error?

--------------
Richard Cavell
Melbourne University Medical Student, Debater, Chess Player, etc.
- r.cavell@ugrad.unimelb.edu.au

Celebrating the Micro$oft breakup.
Newsgroups - Please copy your replies to me via email. (Server problems).


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <Pine.OSF.4.10.10006251824480.11012-100000@cassius.its.unimel
b.edu.au>, Richard John Cavell <rjcavell@student.unimelb.edu.au> writes
>NULL is often used to return an 'invalid' output, particularly with
>pointers.  NULL generally equals zero.
>
>Is there any example of an implementation where NULL has not equalled
>zero?

This is not a very well defined question. You are pre-occupied with
representations (I think). The NULL pointer constant is written as zero,
the bit pattern representing it is not required to be 'all bits zero'
nor is it required to match any other zero for any other type (think of
the ways that floating point zeroes might be represented).  However any
null pointer is required to evaluate to false in any context where a
boolean value is required. In addition any valid comparison of a null-
pointer with zero is required to return true, and any valid comparison
with any non zero value it is required to return false.

However that does not say much because there are not many things you may
compare pointers with other than pointers.

Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Richard John Cavell wrote:
>
> Hi,
>
> NULL is often used to return an 'invalid' output, particularly with
> pointers.  NULL generally equals zero.
>
> Is there any example of an implementation where NULL has not equalled
> zero?
>
> Can I always do:
>
> if (!pClass)
> {//error}
>
> where pClass==NULL indicates an error?

NULL is required by the C++ standard to be a null pointer constant. A
null pointer constant is defined to be "an integral constant expression
(5.19) rvalue of integer type that evaluates to zero." Therefore, in C++
NULL is guaranteed to compare equal to 0. That's also true in C, but the
reasons are much more complicated.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> In article <Pine.OSF.4.10.10006251824480.11012-100000@cassius.its.unimel
> b.edu.au>, Richard John Cavell <rjcavell@student.unimelb.edu.au> writes
> >NULL is often used to return an 'invalid' output, particularly with
> >pointers.  NULL generally equals zero.
> >
> >Is there any example of an implementation where NULL has not equalled
> >zero?
>
> This is not a very well defined question. You are pre-occupied with
> representations (I think). The NULL pointer constant is written as zero,
> the bit pattern representing it is not required to be 'all bits zero'
> nor is it required to match any other zero for any other type (think of
> the ways that floating point zeroes might be represented).  However any
> null pointer is required to evaluate to false in any context where a
> boolean value is required. In addition any valid comparison of a null-
> pointer with zero is required to return true, and any valid comparison
> with any non zero value it is required to return false.
>
> However that does not say much because there are not many things you may
> compare pointers with other than pointers.

Your statements are perfectly correct about null pointers. However, NULL
is required to be a null pointer constant, which means that in C++ it's
required to NOT be a null pointer. Null pointers are required to have
pointer types, null pointer constants are required to have integer type.

A null pointer constant is an expression with an integer type, and value
zero. So if NULL is stored in an integer variable of any type, the
conversion is well-defined (value preserving), and all of the value bits
of that variable WILL be 0.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3956AE1E.ADEDBFB2@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
>
> A null pointer constant is an expression with an integer type, and
value
> zero. So if NULL is stored in an integer variable of any type, the
> conversion is well-defined (value preserving), and all of the value
bits
> of that variable WILL be 0.

Is that really true? On a 1-s complement machine, couldnt the value bits
all be 1?

-------------
Mark Williams


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3956AE1E.ADEDBFB2@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> Francis Glassborow wrote:
> > This is not a very well defined question. You are pre-occupied with
> > representations (I think). The NULL pointer constant is written as
> > zero,
> > the bit pattern representing it is not required to be 'all bits
> > zero'
> > nor is it required to match any other zero for any other type[snip]
> A null pointer constant is an expression with an integer type, and
> value
> zero. So if NULL is stored in an integer variable of any type, the
> conversion is well-defined (value preserving), and all of the value
> bits
> of that variable WILL be 0.
But it then becomes an *integer* and is no longer the null pointer
constant.

Consider this code fragment:

void f()
{
   int *p;
   int i=NULL;
   p = reinterpret_cast<int *>(i);
   if (p == NULL) {
      doSomething();
   } else {
      doSomethingElse();
   }
}

Since 'i' is not the null pointer constant, the compiler is under no
constraint to make 'p' a null pointer - the if test could evaluate to
false.

--
Jim
I ignore all email from recruitment agencies.  Except that
I reserve the right to send rude, nasty replies to recruiters.
Please do not send me email with questions - post
here.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Mark Williams wrote:
>
> In article <3956AE1E.ADEDBFB2@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
> >
> > A null pointer constant is an expression with an integer type, and
> value
> > zero. So if NULL is stored in an integer variable of any type, the
> > conversion is well-defined (value preserving), and all of the value
> bits
> > of that variable WILL be 0.
>
> Is that really true? On a 1-s complement machine, couldnt the value bits
> all be 1?
>
No.  0 will be all zeros.  There's also this quirky
-0 value (all ones), but that's almost always only generated as a result of
an operation, not a literal store.

But your point is well taken, the standard makes no guarantees about how
values are stored in memory, just their "value" when used in programs.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Mark Williams wrote:
>
> In article <3956AE1E.ADEDBFB2@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
> >
> > A null pointer constant is an expression with an integer type, and
> value
> > zero. So if NULL is stored in an integer variable of any type, the
> > conversion is well-defined (value preserving), and all of the value
> bits
> > of that variable WILL be 0.
>
> Is that really true? On a 1-s complement machine, couldnt the value bits
> all be 1?

I remember reading a claim about integer representations that provide
two different ways of representing 0. The claim was that the standard
requires that the when a value equal to 0 is actually stored, it should
be stored in the representation with all value bits set to 0, even if
the expression creating that value created the other representation
instead. I can't find textual support for this claim, however.

If that's not the case, then you're correct.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jim Hyslop wrote:
>
> In article <3956AE1E.ADEDBFB2@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
....
> > A null pointer constant is an expression with an integer type, and
> > value
> > zero. So if NULL is stored in an integer variable of any type, the
> > conversion is well-defined (value preserving), and all of the value
> > bits
> > of that variable WILL be 0.
> But it then becomes an *integer* and is no longer the null pointer
> constant.

NULL is "a" null pointer constant (NPC), not "the" NPC. There are a
practical infinity of NPCs, including 0, (1-1), (2-2), (1+2-3), (2*2-4),
(3/2-1), etc.

> Consider this code fragment:
>
> void f()
> {
>    int *p;
>    int i=NULL;
>    p = reinterpret_cast<int *>(i);
>    if (p == NULL) {
>       doSomething();
>    } else {
>       doSomethingElse();
>    }
> }
>
> Since 'i' is not the null pointer constant, the compiler is under no
> constraint to make 'p' a null pointer - the if test could evaluate to
> false.

Agreed. However, such code has not been the subject of this discussion.
I mentioned storing the value in an integer, only for the purpose of
making the question of the value of it's bits more concrete. That may
have been a bad choice.

The original poster used two expressions, implying that they were
equivalent:
1. !pClass
pClass is implicitly converted to bool 5.3.1p8
A null pointer value (NPV) converted to bool is converted to false, all
other pointer values are converted to true. 4.12
!pClass therefore have a value of true if pClass is an NPV, and false
otherwise. 5.3.1 p8

2. pClass==NULL.
A pointer compared for equality with a NPC causes the NPC to be
converted to the same type as the pointer. 5.10p2
The result of that conversion is an NPV. 4.10p1
An NPV compares equal to another pointer of the same type if and only if
that pointer is also an NPV. 5.10 p1.

Therefore, both expressions are equal, and work exactly as the original
poster apparently desired: they test whether pClass has an NPV. As you
correctly point out, whether pClass has an NPV is implementation defined
if it's been filled in by reinterpret_cast<> of an integer expression
that is not an NPC.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Mark Williams <markw65@my-deja.com> wrote:
>In article <3956AE1E.ADEDBFB2@wizard.net>,
>  James Kuyper <kuyper@wizard.net> wrote:
>>
>> A null pointer constant is an expression with an integer type, and
>value
>> zero. So if NULL is stored in an integer variable of any type, the
>> conversion is well-defined (value preserving), and all of the value
>bits
>> of that variable WILL be 0.
>
>Is that really true? On a 1-s complement machine, couldnt the value bits
>all be 1?

That's why I usually follow the advice of my colleague, a member of
ANSI-C++-std and redefine the confusing null/NULL/0 in my headerfile:

// I hate to use NULL, but I hate magic numbers even more
const long null = 0L;

and use null in my program as sentinel.

DJ Java


_______________________________________________
M$_Upgrade: Windows2000 - Windows98 = 2 Windows
Submitted via free WebNewsReader of http://www.InterBulletin.com
Any spamming complaints please send to abuse@interbulletin.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> wrote:
>> A null pointer constant is an expression with an integer type, and
>> value zero. So if NULL is stored in an integer variable of any type,
>> the conversion is well-defined (value preserving), and all of the
>> value bits of that variable WILL be 0.

Mark Williams <markw65@my-deja.com> wrote:
>> Is that really true? On a 1-s complement machine, couldnt the value
>> bits all be 1?

Any null pointer must compare equal to (integer) zero, regardless of
its internal bit pattern.  Converting a null pointer into an integer
could very well result in a non-zero integer value, though.  Comparing
and converting pointers are two different operations.

These must all hold true:

    int *  ip = 0;
    int    i =  0;

    if (ip == NULL) ...    // always true
    if (ip == 0) ...       // always true
    if (ip == i) ...       // always true

    ip = (int *) i;        // must result in a null pointer
    i = (int) ip;          // may result in a nonzero integer

DJ Java wrote:
> That's why I usually follow the advice of my colleague, a member of
> ANSI-C++-std and redefine the confusing null/NULL/0 in my headerfile:
>
> // I hate to use NULL, but I hate magic numbers even more
> const long null = 0L;
>
> and use null in my program as sentinel.

It's been posted here several times before, but here is a more
type-safe version of 'null' that makes it look and act more like a
built-in keyword:

    class Null_
    {
    public:
        template <class T> operator T*() const
        {
            return ((T*) 0);
        }
    private:
        /*void*/    Null_(const Null_ &r);
        void        operator &();
    };

    const Null_     null;       // Generic null pointer constant

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
>     if (ip == i) ...       // always true

Sorry.  i is not an null pointer constant (must be a constant expression).
This shouldn't even compile.  You can't compare pointers and integers.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Consider this then! The NULL pointer is a symbol that is used by the
compiler to return a specific value when used in certain context such as
when it is used in-
if (!pClass) the compiler substitutes the false value in because the pointer
is NULL and the if (!pClass) statement is calling for a true or false value
which is determined when the '!' was typed.

-Nick Dziedzic-


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>// I hate to use NULL, but I hate magic numbers even more
>const long null = 0L;
>
>and use null in my program as sentinel.
>
>DJ Java

I don't understand what the advantage of this is over :

#define NULL 0

?


--
Mike Davies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>It's been posted here several times before, but here is a more
>type-safe version of 'null' that makes it look and act more like a
>built-in keyword:
>
>    class Null_
>    {
>    public:
>        template <class T> operator T*() const
>        {
>            return ((T*) 0);
>        }
>    private:
>        /*void*/    Null_(const Null_ &r);
>        void        operator &();
>    };
>
>    const Null_     null;       // Generic null pointer constant
>
>--
>David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

I don't understand what the advantage of this is either ?



--
Mike Davies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <iTSJQEAt2RW5Ew5z@noco.demon.co.uk>,
Mike Davies  <mike_davies@noco.demon.co.uk> wrote:
>>It's been posted here several times before, but here is a more
>>type-safe version of 'null' that makes it look and act more like a
>>built-in keyword:
>
>I don't understand what the advantage of this is either ?

Given

    void foo (int)
    void foo (bar *)

and NULL == 0,

    foo(NULL)

(which is nice to think of as foo((bar *)NULL)) calls foo(int) and not
foo(bar *).

--
--
<a href="http://www.poohsticks.org/drew/">Home Page</a>
For those who do, no explanation is necessary.
For those who don't, no explanation is possible.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]