References for machines where NULL is not zero.

[pm940]

Hello.

I've been reading some past discussions on the NULL vs. zero.
References are always made to systems or machienes that use values
other than zero to represent the NULL pointer.

Although not a practice I follow, there are no doubt millions of lines
of open source libraries and applications that do things like:

p = malloc(...);
if (!p)
fail.

Which is obviously a bad thing on non-zero NULL machines.



Can anybody provide specific examples of modern machines/systems be
them embedded or supercomputer where NULL is not zero?

The standard says what the standard says and I don't want to debate it.
Rather, I want to find counter-examples to prove that the standard's
language still relevant.

Thanks,
Paul.

 

[Artie Gold]

Hello.

I've been reading some past discussions on the NULL vs. zero.
References are always made to systems or machienes that use values
other than zero to represent the NULL pointer.

Although not a practice I follow, there are no doubt millions of lines
of open source libraries and applications that do things like:

p = malloc(...);
if (!p)
fail.

Which is obviously a bad thing on non-zero NULL machines.

No, not at all. Whatever the actual bit representation of a null pointer
on a given machine, the above works.HTH,
--ag

 

[Chris Torek]

References are always made to systems or machienes that use values
other than zero to represent the NULL pointer.
("Always"?)

Although not a practice I follow, there are no doubt millions of lines
of open source libraries and applications that do things like:

p = malloc(...);
if (!p)
fail.

Which is obviously a bad thing on non-zero NULL machines.

This is fine on "non-zero NULL machines". The expression "!p"
means "p != 0" which means "p != NULL". All three expressions
are guaranteed by the C Standards to produce the same result.

Can anybody provide specific examples of modern machines/systems be
them embedded or supercomputer where NULL is not zero?

Define "modern". My definition is "anything made since 1965",
in which case the PR1ME qualifies. On the original PR1ME, a
NULL pointer is represented internally as 017777600000 (see
<http://seclists.org/linux-kernel/2000/Jul/0872.html>).

Nonetheless, a C compiler for the PR1ME must turn:

if (!p) ...

into a "test p to see if it is 017777600000" instruction sequence
(and if so, execute the "..." part).

 

[Gordon Burditt]

I've been reading some past discussions on the NULL vs. zero.

References are always made to systems or machienes that use values
other than zero to represent the NULL pointer.

Although not a practice I follow, there are no doubt millions of lines
of open source libraries and applications that do things like:

p = malloc(...);
if (!p)
fail.

Which is obviously a bad thing on non-zero NULL machines.

No, it is *NOT* obviously a bad thing. It should work fine, *EVEN
ON MACHINES WHERE NULL IS NOT all-bits-zero*. This might generate
the machine code:

cmpl r7,#0xdeadbeef
jne .L134
... code for "fail" ...
..L134:


Note that even on 32-bit machines, the representation of NULL is
*NOT* guaranteed to be 0xdeadbeef, and on 64-bit machines, the
representation of NULL is *NOT* guaranteed to be 0xdeadbeefdeadbeef.

Can anybody provide specific examples of modern machines/systems be
them embedded or supercomputer where NULL is not zero?

The standard says what the standard says and I don't want to debate it.
Rather, I want to find counter-examples to prove that the standard's
language still relevant.

Gordon L. Burditt

 

[pm940]

No, it is *NOT* obviously a bad thing. It should work fine, *EVEN
ON MACHINES WHERE NULL IS NOT all-bits-zero*. This might generate
the machine code:

cmpl r7,#0xdeadbeef
jne .L134
... code for "fail" ...
.L134:

Yeah, you got me. My bad. Thanks for the correction.

Ok... a-hem... moving swiftly on...


Can anybody provide specific examples of modern machines/systems be
them embedded or supercomputer where NULL is not zero?


Thanks,
Paul.

 

[pm940]

Define "modern".

How about: Likely to be encountered by a 'C' programmer today and for
which compilers are actively being developed. As opposed to a
historically interesting machine or similar curiosity.



And thanks for the clarification.


Regards,
Paul.

 

[pm940]

How about: Likely to be encountered by a 'C' programmer today and for
which compilers are actively being developed. As opposed to a
historically interesting machine or similar curiosity.

.... but if you want a specific date range I'd say any computer system /
CPU available to buy brand new in the last 15 years.

Paul.

 

[Dik T. Winter]

>
> Define "modern". My definition is "anything made since 1965",
> in which case the PR1ME qualifies. On the original PR1ME, a
> NULL pointer is represented internally as 017777600000 (see
> <http://seclists.org/linux-kernel/2000/Jul/0872.html>).

Did not the Data General MV series have null-pointers with the ring
number embedded in the upper four bits? And so the null-pointer
value depended on the ring your routine, program, or whatever
executed in? And, yes, the compiler had to do the right thing.

 

[Martin Ambuhl]

Hello.

I've been reading some past discussions on the NULL vs. zero.
References are always made to systems or machienes that use values
other than zero to represent the NULL pointer.

Although not a practice I follow, there are no doubt millions of lines
of open source libraries and applications that do things like:

p = malloc(...);
if (!p)
fail.

Which is obviously a bad thing on non-zero NULL machines.

It is *not* "obviously a bad thing". The C standard guarantees this
will work as the coder expected.

Can anybody provide specific examples of modern machines/systems be
them embedded or supercomputer where NULL is not zero?

Since you are confused about what the implications might be, such a
discussion would be counterproductive.

The standard says what the standard says and I don't want to debate it.

But you *should* learn what the standard says. Your "obviously a bad
thing" line shows that you don't yet have a clue.

Rather, I want to find counter-examples to prove that the standard's
language still relevant.

Why don't you read it first before trying to critique it?

 

[Keith Thompson]

I've been reading some past discussions on the NULL vs. zero.
References are always made to systems or machienes that use values
other than zero to represent the NULL pointer.

Although not a practice I follow, there are no doubt millions of lines
of open source libraries and applications that do things like:

p = malloc(...);
if (!p)
fail.

Which is obviously a bad thing on non-zero NULL machines.

See section 5 of the C FAQ.

 

[Chris Torek]

Did not the Data General MV series have null-pointers with the ring
number embedded in the upper four bits?

The Eclipse did have ring numbers in its pointers. I do not know
(having never investigated) whether it used/required them in null
pointers in rings other than "ring 0". I believe ring 0 was "user
mode", so that a "user level NULL" was all-zero-bits, though.

And so the null-pointer value depended on the ring your routine,
program, or whatever executed in? And, yes, the compiler had to
do the right thing.

I only ever wrote user-mode code on ours.

 

[pm940]

p = malloc(...);
if (!p)
fail.
Which is obviously a bad thing on non-zero NULL machines.

No, not at all.

No, it is *NOT* obviously a bad thing.

This is fine on "non-zero NULL machines".

It is *not* "obviously a bad thing".

See section 5 of the C FAQ.

Ok ok ok... Horse, flogged, dead. My bad, I clearly didn't know what
I was talking about... or as Martin Ambuhl so eloquently put it:

Your "obviously a bad thing" line shows that you don't yet have a clue.

Indeed.


Thanks for the collective slapping. Info assimilated.


Still, I am interested in knowing if there are modern (relatively new,
within the last 15 years) C compilers for equally modern systems that
are out there in the world doing real work that use non-zero values for
NULL.

I'm not aware of any... but as we've discovered, my awareness is
lacking.

I'm not critiquing non-zero NULL... Clearly I'm not even capable of
B.S.-ing an argument. Just asking the question.

Regards,
Paul.

P.S. Chris: "modern is 'anything made since 1965'" made me laugh...
well, chuckle... ok it made me smile. I like playing "remember
when...?".

 

[Chris Torek]

P.S. Chris: "modern is 'anything made since 1965'" made me laugh...
well, chuckle... ok it made me smile. I like playing "remember
when...?".

Earlier (with the stray thread on glyphs and ROMs and the like),
I was thinking about some of the remarks about computers today
compared to the ones available however-many years ago:

"Back in my day, we didn't have any fancy graphics, our
characters were in ROMs!"

"You had ROMs? We had to work with discrete logic, all zeros
and ones!"

"Ones? You had ONES?!"



(I started playing with computers in 1978 or so, myself. I had
been making my own PC-boards with a resist pen and etch, and building
stuff out of TTL, before that. By the time I was able to "borrow"
the local community college's facilities, "glass tty"s had already
been replaced with screens capable of full-screen editing.

My first summer job was working on an HP3060A board testing system,
with a HP2621A display terminal, if I remember the numbers right.

I was introduced to C in 1981, when I went to the University of
Maryland. That made me a relative latecomer -- I never even used
Version 6 C, with its "=+" instead of "+=" operators, for instance.)

 

[Christian Bau]

Hello.

I've been reading some past discussions on the NULL vs. zero.
References are always made to systems or machienes that use values
other than zero to represent the NULL pointer.

Although not a practice I follow, there are no doubt millions of lines
of open source libraries and applications that do things like:

p = malloc(...);
if (!p)
fail.

Which is obviously a bad thing on non-zero NULL machines.

Which means you are very very confused. !p, by definition, produces a
value of 1 if p is a null pointer and 0 if p is not a null pointer.

There is _no_ machine where a null pointer is zero. A null pointer is a
pointer, zero is a number. Pointers and numbers are different things.
They _cannot_ be the same. How could anyone even entertain the _thought_
that a pointer could be zero? The whole notion is complete _nonsense_. A
pointer cannot be zero, or one, or 999, or any number. It is a pointer,
not a number.

Get a copy of the C Standard or a good book and read what a "null
pointer constant" is. 0 is a null pointer constant, it is not a pointer.
In some situations, a null pointer constant is converted to a pointer,
and becomes a null pointer.

On some machines, the _representation_ of a null pointer has not all
bits equal to zero.

unsigned char a [sizeof (void *)];
void* p = NULL;
int i;

memcpy (a, &p, sizeof (p));
for (i = 0; i < sizeof (p); ++i) {
if (a != 0) {
printf ("Null pointer has non-zero representation!\n");
break;
}
}

may print that a null pointer has a non-zero representation.

union {
unsigned int ul;
void* p;
} u;

u.p = NULL;
if (ul != 0) printf ("Null pointer has non-zero representation!");

invokes undefined behavior when executed. On _every_ machine.

 

[Tim Rentsch]

union {
unsigned int ul;
void* p;
} u;

u.p = NULL;
if (ul != 0) printf ("Null pointer has non-zero representation!");

invokes undefined behavior when executed. On _every_ machine.

(Assuming 'u.ul != 0' was intended rather than 'ul != 0'...)

What part(s) of the Standard say that this test yields
undefined behavior? Annex J gives "The value of a union
member other than the last one stored into (6.2.6.1)" as
unspecified behavior, not undefined behavior.

 

[Walter Roberson]

I was thinking about some of the remarks about computers today
compared to the ones available however-many years ago:

"Back in my day, we didn't have any fancy graphics, our
characters were in ROMs!"

"You had ROMs? We had to work with discrete logic, all zeros
and ones!"

"Ones? You had ONES?!"

Ah, but the analog computers didn't -have- ones! ;-)

 

[Skarmander]

Which means you are very very confused. !p, by definition, produces a
value of 1 if p is a null pointer and 0 if p is not a null pointer.

Yes. "By definition" is the appropriate phrase here.

There is _no_ machine where a null pointer is zero. A null pointer is a
pointer, zero is a number. Pointers and numbers are different things.
They _cannot_ be the same. How could anyone even entertain the _thought_
that a pointer could be zero?

When interpreted as pointing to what is colloquially referred to as
"memory", many envision these pointers as so-called "indexes" of "cells"
numbered consecutively from a base offset. The numerical labels of these
cells are "addresses".

I see what you mean, but there's no need to lay it on so thick. You're
formulating it as if the very *notion* of identifying a pointer with a
number is unthinkable. Last time I checked, C books that illustrated
pointers as if they contained numbers where not widely castigated for
promoting a completely wrong point of view.

If there's *any* language that doesn't get to act high and mighty when
people start digging into things they shouldn't be digging in, it's C.

The whole notion is complete _nonsense_. A pointer cannot be zero, or
one, or 999, or any number. It is a pointer, not a number.

Which is why casting a pointer to a long is simply invalid, and any good
C compiler will refuse to process a program containing such a completely
nonsensical statement.

Well, not exactly, of course. C has shades of nonsensicalness, and this
isn't completely off the bat.

Get a copy of the C Standard or a good book and read what a "null
pointer constant" is. 0 is a null pointer constant, it is not a pointer.
In some situations, a null pointer constant is converted to a pointer,
and becomes a null pointer.

On some machines, the _representation_ of a null pointer has not all
bits equal to zero.

<snip>
It's all very logical and sensible once you understand it. It also takes
up a whole chapter in the FAQ. There is a message here, and it's not
necessarily "how could you even entertain such thoughts?"

S.

 

[Christian Bau]

(Assuming 'u.ul != 0' was intended rather than 'ul != 0'...)

What part(s) of the Standard say that this test yields
undefined behavior? Annex J gives "The value of a union
member other than the last one stored into (6.2.6.1)" as
unspecified behavior, not undefined behavior.

Much earlier in the C Standard: Reading an object through an lvalue of
type unsigned long, when the value was not stored through an lvalue of
type unsigned long, long, or a char type.

Annex J applies for something like

union {
unsigned long one_unsigned_long;
unsigned long another_unsigned_long;
} u;

 

[Tim Rentsch]

Much earlier in the C Standard: Reading an object through an lvalue of
type unsigned long, when the value was not stored through an lvalue of
type unsigned long, long, or a char type.

The section I think you're referring to is 6.5 p6,p7, discussing
effective type and object access. However, if you look at 6.5 p6 I
believe you'll see that the part about the last stored value applies
only to objects having no declared type. The variable u, and its
members u.ul and u.p, all have a declared type. So what type of value
was last stored doesn't affect the legality or non-legality of the
access in this case.

 

[Kevin D. Quitt]

How about: Likely to be encountered by a 'C' programmer today and for
which compilers are actively being developed. As opposed to a
historically interesting machine or similar curiosity.

How about every x86 machine, where there's a segment and offset, and only the offset need
be zero for NULL.