What platform has a non-zero null pointer?
Crosbie Fitch
void* p=0;
defines a pointer initialised to null.
But, that
cout<<(*(long*)&p)<<endl;
is not necessarily going to print out '0'.
Is there (or has there ever been) a platform/compiler for which the binary
representation of the null pointer is non-zero?
I suspect that some 8086 based C compilers may allow non-zero pointers which
compare equal to the null pointer, but I doubt that they've ever used one of
these non-zero null pointers as the default null pointer.
If there has been a C compiler that used a non-zero null pointer, I'd like
to know if it initialised static pointers to all bits zero, or the null
pointer representation (I suspect the latter). I guess this is similar to a
hypothetical FPUs where a zero value may not be represented by all bits zero
(a bit silly, but possible I guess).
Sorry if this is 'counting angels on a pinhead', but it's been nagging me...
;-)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Ron Natalie
>
> Is there (or has there ever been) a platform/compiler for which the binary
> representation of the null pointer is non-zero?
I am not aware of any that actually got built. However, there was a machine
called S1 proposed that would trap when 0's got stored in pointer contexts.
This would mean that the compiler would have either had to use the right
null pointer value (they did define such) or be very careful to not allow
null pointer values near the trapping contexts. I lobbied the designers
to fix this because while technically a compiler could fix null pointers,
I thought it would just cause nightmares otherwise.
> I suspect that some 8086 based C compilers may allow non-zero pointers which
> compare equal to the null pointer, but I doubt that they've ever used one of
> these non-zero null pointers as the default null pointer.
>
However, I'd avoid making any assumption on pointer behavior. While this
one is probably pretty benign, the community has been bitten in a large
way before.
Back in the early C compiler days on the PDP-11, the location 0 was
actually (if dereferenced) the beginning of the instrutions of the
program (many awry print statemnts yielded p&P6, sort of what setd
and the following instructions looked like when printed as a zstring).
When the VAX came out, instruction and data were split (actually, we
had been doing so on some PDP-11 stuff before that as well) and someone
got the great idea of putting a zero at location zero. Lots of code
got sloppy and trusted that *0 = 0. When we moved to another platform
(Gould) that trapped when you tried to access location zero, lots of
applications ported from the VAX stopped working. Gould finally put
in a feature you could poke into the header of the executable (for the
most annoying culprits were applications that you didn't have the source
to fix) that turned on what the Gould engineers called "braindamaged
VAX compatibility mode" which supressed the trap.
Later, I was porting UNIX to a supercomputer. There had been a tacit
assumption that all pointers on the system had the same layout. The
Berkeley kernel all over the place did conversion by union:
union {
char* cp;
short* sp;
int* ip;
};
and they would store a pointer of one type into the union and retrieve]
it by another. The only problem is that this computer for all but char
accesses, encoded the size of the operand in the low order bits of the
pointer. While our compiler (written by the late Mike Muuss) was smart
enough to do the right thing on casted conversions, the above construct
caused bizzare behavior when random operand sizes were used instead of
what the programmers intended.
MORAL: Despite what you think you can get away with FOLLOW THE DARN
LANGUAGE RULES and make life for you and your successors less painful.
Andrew Koenig
binary
Crosbie> representation of the null pointer is non-zero?
I don't know about C compilers, but the PL/I compiler for the IBM 360
and 370 computers used hex FF000000 to represent a null pointer.
This was in the days when these machines were limited to a 16-megabyte
address space; I don't know what they did when they went to 32-bit
addressing.
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark
Carlos Moreno
Crosbie Fitch wrote:
>
> I know that
>
> void* p=0;
>
> defines a pointer initialised to null.
>
> But, that
>
> cout<<(*(long*)&p)<<endl;
>
> is not necessarily going to print out '0'.
Actually, it's not necessarily going to print anything, since
you are dereferencing a NULL pointer, and thus invoking undefined
behaviour. You probably meant cout << ((long *) &p), or even
better, cout << ((void *) &p)
In that case, cout might even decide to print (NULL), or (null),
or simply NULL, or 0.
Think of NULL as a magical value that the compiler knows -- for
you, that value is *called* NULL, or its synonim, 0
Carlos
--
Ed Kaulakis
architecture, bounded pointers, hardware lexical scoping), but there's a
pretty good chance that a C(++)? implementation on such a machine would have
some 1-bits in the representation of a null pointer.
"Crosbie Fitch" <anne.c...@btopenworld.com> wrote in message
news:9ml3ci$25q$1...@uranium.btinternet.com...
Phil Carmody
>
> I know that
>
> void* p=0;
>
> defines a pointer initialised to null.
>
> But, that
>
> cout<<(*(long*)&p)<<endl;
>
> is not necessarily going to print out '0'.
>
> Is there (or has there ever been) a platform/compiler for which the binary
> representation of the null pointer is non-zero?
Yes. Many years ago I worked with a system which had to read/write reset
vectors at location 0x000000 on a 68K family machine. The null pointer
was represented as 0xC00000, IIRC. (only 24 bits of the 32-bit address
registers were actually used for address generation on that particular
processor.)
Phil
Ron Natalie
> >
> > cout<<(*(long*)&p)<<endl;
> >
> > is not necessarily going to print out '0'.
>
> Actually, it's not necessarily going to print anything, since
> you are dereferencing a NULL pointer, and thus invoking undefined
> behaviour. You probably meant cout << ((long *) &p), or even
> better, cout << ((void *) &p)
>
He does not derefence a null pointer. The * is applied to
the result of the conversion of the ADDRESS of the pointer
containing the null pointer value to long*.
James Dennett
> Crosbie Fitch wrote:
>
>>I know that
>>
>>void* p=0;
>>
>>defines a pointer initialised to null.
>>
>>But, that
>>
>>cout<<(*(long*)&p)<<endl;
>>
>>is not necessarily going to print out '0'.
>>
>
> Actually, it's not necessarily going to print anything, since
> you are dereferencing a NULL pointer, and thus invoking undefined
> behaviour.
There's no dereference of a NULL pointer; the pointer which
is dereferenced is (long*)&p, and &p is not NULL so it stays
non-NULL when cast to (long *) -- probably, at least.
> You probably meant cout << ((long *) &p), or even
> better, cout << ((void *) &p)
I suspect he wanted to reinterpret the bit pattern of the
pointer p as a long, assuming that sizeof(long)==sizeof(void*).
Reading the bits out as unsigned chars would be the better way
to do this.
-- James Dennett
Chris Uzdavinis
> Crosbie Fitch wrote:
> >
> > void* p=0;
> > cout<<(*(long*)&p)<<endl;
> >
> > is not necessarily going to print out '0'.
>
> Actually, it's not necessarily going to print anything, since
> you are dereferencing a NULL pointer, and thus invoking undefined
> behaviour. You probably meant cout << ((long *) &p), or even
> better, cout << ((void *) &p)
The variable p is not stored at address zero, so taking its address
will not yield a null pointer. The address will be nonzero, and
dereferencing that is always going to be safe (while p is in scope at
least), returning the value of p (0).
But due to the cast, we'll see the bit pattern of how null is
physically stored, which is probably (but not necessarily) zero. In
any case, null itself will not be dereferenced.
--
Chris
Sebastian Kapfer
|
| Crosbie Fitch wrote:
| >
| > I know that
| >
| > void* p=0;
| >
| > defines a pointer initialised to null.
| >
| > But, that
| >
| > cout<<(*(long*)&p)<<endl;
| >
| > is not necessarily going to print out '0'.
|
| Actually, it's not necessarily going to print anything, since
| you are dereferencing a NULL pointer, and thus invoking undefined
| behaviour. You probably meant cout << ((long *) &p), or even
| better, cout << ((void *) &p)
(*(long*)&p) doesn't dereference a NULL pointer. It casts a void ** to a
long * (reinterpret_cast?), and dereferences that.
| In that case, cout might even decide to print (NULL), or (null),
| or simply NULL, or 0.
I agree it's undefined behaviour, since casting a void ** to a long *
might not be possible. On some platforms, this code segment will print
whatever the bit pattern of (void *)NULL means interpreted as a long.
sk
Francis Glassborow
<anne.c...@btopenworld.com> writes
>Is there (or has there ever been) a platform/compiler for which the binary
>representation of the null pointer is non-zero?
>
>I suspect that some 8086 based C compilers may allow non-zero pointers
which
>compare equal to the null pointer, but I doubt that they've ever used one
of
>these non-zero null pointers as the default null pointer.
Well you would be mistaken. Just to name one of which I am absolutely
certain Salford C and Salford C++ used non-zero null pointers.
>
>If there has been a C compiler that used a non-zero null pointer, I'd like
>to know if it initialised static pointers to all bits zero, or the null
>pointer representation (I suspect the latter).
What it is required to do by the standard, which is to initialise it as
if the programmer had specifically initialised it to 0 (in the case of
pointers that would be the null pointer constant)
>I guess this is similar to a
>hypothetical FPUs where a zero value may not be represented by all bits
zero
>(a bit silly, but possible I guess).
What's hypothetical about it? And why silly? Very difficult to have all
bits zero on odd parity hardware.
Francis Glassborow ACCU
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Jon Bell
Crosbie Fitch <anne.c...@btopenworld.com> wrote:
>
>Is there (or has there ever been) a platform/compiler for which the binary
>representation of the null pointer is non-zero?
Prime minicomputers, which used the PRIMOS operating system, had null
pointers in which the bit representation was not zero. They've been
orphans since the mid 1990s; I don't know how many of them are still in
use.
--
Jon Bell <jtb...@presby.edu> Presbyterian College
Dept. of Physics and Computer Science Clinton, South Carolina USA
Carlos Moreno
Ron Natalie wrote:
>
> > >
> > > cout<<(*(long*)&p)<<endl;
> > >
> > > is not necessarily going to print out '0'.
> >
> > Actually, it's not necessarily going to print anything, since
> > you are dereferencing a NULL pointer, and thus invoking undefined
> > behaviour. You probably meant cout << ((long *) &p), or even
> > better, cout << ((void *) &p)
> >
>
> He does not derefence a null pointer. The * is applied to
> the result of the conversion of the ADDRESS of the pointer
> containing the null pointer value to long*.
Hmmm... errrr... What was I thinking, again? :-)
Carlos
--
Maurizio Loreti
> Is there (or has there ever been) a platform/compiler for which the binary
> representation of the null pointer is non-zero?
From the comp.lang.c FAQ list, available under
http://www.eskimo.com/~scs/C-faq/top.html:
5.17: Seriously, have any actual machines really used nonzero null
pointers, or different representations for pointers to different
types?
A: The Prime 50 series used segment 07777, offset 0 for the null
pointer, at least for PL/I. Later models used segment 0, offset
0 for null pointers in C, necessitating new instructions such as
TCNP (Test C Null Pointer), evidently as a sop to all the extant
poorly-written C code which made incorrect assumptions. Older,
word-addressed Prime machines were also notorious for requiring
larger byte pointers (char *'s) than word pointers (int *'s).
The Eclipse MV series from Data General has three
architecturally supported pointer formats (word, byte, and bit
pointers), two of which are used by C compilers: byte pointers
for char * and void *, and word pointers for everything else.
Some Honeywell-Bull mainframes use the bit pattern 06000 for
(internal) null pointers.
The CDC Cyber 180 Series has 48-bit pointers consisting of a
ring, segment, and offset. Most users (in ring 11) have null
pointers of 0xB00000000000. It was common on old CDC ones-
complement machines to use an all-one-bits word as a special
flag for all kinds of data, including invalid addresses.
The old HP 3000 series uses a different addressing scheme for
byte addresses than for word addresses; like several of the
machines above it therefore uses different representations for
char * and void * pointers than for other pointers.
The Symbolics Lisp Machine, a tagged architecture, does not even
have conventional numeric pointers; it uses the pair <NIL, 0>
(basically a nonexistent <object, offset> handle) as a C null
pointer.
Depending on the "memory model" in use, 8086-family processors
(PC compatibles) may use 16-bit data pointers and 32-bit
function pointers, or vice versa.
Some 64-bit Cray machines represent int * in the lower 48 bits
of a word; char * additionally uses the upper 16 bits to
indicate a byte address within a word.
References: K&R1 Sec. A14.4 p. 211.
--
Maurizio Loreti http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy lor...@pd.infn.it
Crosbie Fitch
I suppose I should have done something like this:
union { void*p; unsigned char b[sizeof(void*)]; } u;
u.p=0;
unsigned t=0;
for (int i=0; i<sizeof(void*)/sizeof(unsigned char); ++i)
t+=static_cast<unsigned>(u.b[i]);
cout<<t<<endl;
This will not necessarily print out '0'.
But, then this isn't quite as succinct or quick to bung in a post to get my
point across. It probably has more bugs in it too. (forgot to include
iostream ! forgot to write main(), argh!).
Hmmn, perhaps we should all stick to Java, and then at least no one will get
confused by pointers. ;-)
"Chris Uzdavinis" <ch...@atdesk.com> wrote in message
news:j6g0a95...@explicit.atdesk.com...
> Carlos Moreno <mor...@mochima.com> writes:
>
> > Crosbie Fitch wrote:
> > >
> > > void* p=0;
> > > cout<<(*(long*)&p)<<endl;
> > >
> > > is not necessarily going to print out '0'.
> >
> > Actually, it's not necessarily going to print anything, since
> > you are dereferencing a NULL pointer, and thus invoking undefined
> > behaviour. You probably meant cout << ((long *) &p), or even
> > better, cout << ((void *) &p)
>
> The variable p is not stored at address zero, so taking its address
> will not yield a null pointer. The address will be nonzero, and
> dereferencing that is always going to be safe (while p is in scope at
> least), returning the value of p (0).
>
> But due to the cast, we'll see the bit pattern of how null is
> physically stored, which is probably (but not necessarily) zero. In
> any case, null itself will not be dereferenced.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
> > Crosbie Fitch wrote:
> > > void* p=0;
> > > cout<<(*(long*)&p)<<endl;
> > > is not necessarily going to print out '0'.
> > Actually, it's not necessarily going to print anything, since you
> > are dereferencing a NULL pointer, and thus invoking undefined
> > behaviour. You probably meant cout << ((long *) &p), or even
> > better, cout << ((void *) &p)
> The variable p is not stored at address zero, so taking its address
> will not yield a null pointer. The address will be nonzero, and
> dereferencing that is always going to be safe (while p is in scope
> at least), returning the value of p (0).
> But due to the cast, we'll see the bit pattern of how null is
> physically stored, which is probably (but not necessarily) zero.
Not necessarily. If long is larger than a pointer (traditionally the
case, before 32 bit machines became the standard), then we'll see some
junk behind the pointer as well. And if long has some trapping
representations (legal, although I'm not sure if any such
implementations actually have existed), we'll get a trap.
--
James Kanze mailto:ka...@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
-- Conseils en informatique orientée objet
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany, Tél.: +49 (0)69 19 86 27
James Kanze
news:<9ml3ci$25q$1...@uranium.btinternet.com>...
> void* p=0;
> defines a pointer initialised to null.
> But, that
> cout<<(*(long*)&p)<<endl;
> is not necessarily going to print out '0'.
It's not necessarily going to print out anything. It could very
easily cause a segment violation or some other sort of hardware
trap:-).
> Is there (or has there ever been) a platform/compiler for which the
> binary representation of the null pointer is non-zero?
Definitly. I haven't worked on one, but I remember reading an article
in the early 80's where the author listed quite a few exotic
architectures. If I recall correctly, there were at least three
machines which used non-zero null pointers; I seem to recall that
Honeywell made one of them, but I could be mistaken there.
> I suspect that some 8086 based C compilers may allow non-zero
> pointers which compare equal to the null pointer, but I doubt that
> they've ever used one of these non-zero null pointers as the default
> null pointer.
> If there has been a C compiler that used a non-zero null pointer,
> I'd like to know if it initialised static pointers to all bits zero,
> or the null pointer representation (I suspect the latter).
The language requirements for "zero initialization" have always been
"as if zero were assigned to the object".
> I guess this is similar to a hypothetical FPUs where a zero value
> may not be represented by all bits zero (a bit silly, but possible I
> guess).
*All* of the FPU's I know of have two representations of zero, on of
which has a bit set to 1.
--
James Kanze mailto:ka...@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
-- Conseils en informatique orientée objet
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany, Tél.: +49 (0)69 19 86 27
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Ron Natalie
> of a word; char * additionally uses the upper 16 bits to
> indicate a byte address within a word.
Just about everything but the cray II was like this.
Byte select the upper 3 bits. And some only have a 24 bit
address register. In either case storing a char* into int*
and back will strip the bits.
Mike Schilling
>
> "Crosbie Fitch" <anne.c...@btopenworld.com> wrote in message
> news:<9ml3ci$25q$1...@uranium.btinternet.com>...
>
> > may not be represented by all bits zero (a bit silly, but possible I
> > guess).
>
> *All* of the FPU's I know of have two representations of zero, on of
> which has a bit set to 1.
The interesting question is whether a float or double with all zero bits
is not equal to zero, not whether there are other representations of
zero. That is, given:
static float arr[1000000];
Can the C++ implementation simply ensure that arr maps to unallocated
demand-zero pages, or does it have to initialize them in some fashion?
James Kanze
news:<3B8FFA82...@ebay.sun.com>...
> James Kanze wrote:
> > "Crosbie Fitch" <anne.c...@btopenworld.com> wrote in message
> > news:<9ml3ci$25q$1...@uranium.btinternet.com>...
> > > I guess this is similar to a hypothetical FPUs where a zero
> > > value may not be represented by all bits zero (a bit silly, but
> > > possible I guess).
> > *All* of the FPU's I know of have two representations of zero, on
> > of which has a bit set to 1.
> The interesting question is whether a float or double with all zero
> bits is not equal to zero, not whether there are other
> representations of zero. That is, given:
> static float arr[1000000];
> Can the C++ implementation simply ensure that arr maps to
> unallocated demand-zero pages, or does it have to initialize them in
> some fashion?
As I said in my posting, the results of zero initialization are the
same as if (integral) 0 had been assigned to the object. How the
system attains that end is its problem. If all zero bits doesn't
represent a floating point zero, then it must do something to ensure
that the contents are not all zero bits.
There are some subilities involved, although the number of machines
they'd actually affect is probably very small. For example, only the
first member of a union is zero initialized, so accessing any other
member before assigning to the union is undefined behavior. And while
all of the members of a struct are zero initialized, there is no
guarantee that any padding bytes are zero initialized, so memcpy'ing
the struct to a unsigned char[] and then checking for all zeros isn't
guaranteed either.
--
James Kanze mailto:ka...@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
-- Conseils en informatique orientée objet
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany, Tél.: +49 (0)69 19 86 27
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mike Schilling
>
> Mike Schilling <mike.sc...@ebay.sun.com> wrote in message
> news:<3B8FFA82...@ebay.sun.com>...
>
> > bits is not equal to zero, not whether there are other
> > representations of zero. That is, given:
>
> > static float arr[1000000];
>
> > Can the C++ implementation simply ensure that arr maps to
> > unallocated demand-zero pages, or does it have to initialize them in
> > some fashion?
>
> As I said in my posting, the results of zero initialization are the
> same as if (integral) 0 had been assigned to the object. How the
> system attains that end is its problem. If all zero bits doesn't
> represent a floating point zero, then it must do something to ensure
> that the contents are not all zero bits.
>
Which is why, as I said in my posting, the interesting cases are where
all-zero-bits isn't the correct initialization for some type, whether it
be floating point or pointer.
> There are some subilities involved, although the number of machines
> they'd actually affect is probably very small. For example, only the
> first member of a union is zero initialized, so accessing any other
> member before assigning to the union is undefined behavior. And while
> all of the members of a struct are zero initialized, there is no
> guarantee that any padding bytes are zero initialized, so memcpy'ing
> the struct to a unsigned char[] and then checking for all zeros isn't
> guaranteed either.
In there cases, since the language has nothing to say about the
non-first-member or padding bytes, zero-initialization causes no
problems.
James Kanze
> James Kanze wrote:
> > There are some subilities involved, although the number of
> > machines they'd actually affect is probably very small. For
> > example, only the first member of a union is zero initialized, so
> > accessing any other member before assigning to the union is
> > undefined behavior. And while all of the members of a struct are
> > zero initialized, there is no guarantee that any padding bytes are
> > zero initialized, so memcpy'ing the struct to a unsigned char[]
> > and then checking for all zeros isn't guaranteed either.
> In there cases, since the language has nothing to say about the
> non-first-member or padding bytes, zero-initialization causes no
> problems.
Right. My point is rather that accidentally counting on any
zero-initialization of these values is undefined behavior, however.
--
James Kanze mailto:ka...@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
-- Conseils en informatique oriente objet
Ziegelhttenweg 17a, 60598 Frankfurt, Germany, Tl.: +49 (0)69 19 86 27
Richard Riehle
> Is there (or has there ever been) a platform/compiler for which the binary
> representation of the null pointer is non-zero?
The issue is whether indirection (a pointer) actually represents an address
or not. One of the things Java has done is promote its indirection (pointers)
beyond the effect of zero. Also, Ada has, from the very beginning, used a
model where one simply declares a value of "null" for the equivalent of a
pointer. In fact, the default value for any declared Ada pointer is null so
there is no danger of referencing odd places in memory.
Richard Riehle
ric...@adaworks.com