References for machines where NULL is not zero.

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.

pm940@yahoo.com wrote:[color=blue]
> 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.
>[/color]
No, not at all. Whatever the actual bit representation of a null pointer
on a given machine, the above works.[color=blue]
>
>[/color]
HTH,
--ag

--
Artie Gold -- Austin, Texas
http://goldsays.blogspot.com (new post 8/5)
http://www.cafepress.com/goldsays
"If you have nothing to hide, you're not trying!"

>I've been reading some past discussions on the NULL vs. zero.[color=blue]
>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.[/color]

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.
[color=blue]
>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.[/color]

Gordon L. Burditt

In article <1128645954.797174.140400@g43g2000cwa.googlegroups .com>
<pm940@yahoo.com> wrote:[color=blue]
>References are always made to systems or machienes that use values
>other than zero to represent the NULL pointer.[/color]

("Always"?)
[color=blue]
>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.[/color]

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.
[color=blue]
>Can anybody provide specific examples of modern machines/systems be
>them embedded or supercomputer where NULL is not zero?[/color]

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).
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

Gordon Burditt wrote:[color=blue][color=green]
> >Which is obviously a bad thing on non-zero NULL machines.[/color]
>
> 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:
>[/color]

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.

Chris Torek wrote:[color=blue]
> Define "modern".[/color]

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.

p...@yahoo.com wrote:[color=blue]
> 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.[/color]

.... 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.

In article <di4hqj02r8i@news2.newsguy.com> Chris Torek <nospam@torek.net> writes:
....[color=blue][color=green]
> >Can anybody provide specific examples of modern machines/systems be
> >them embedded or supercomputer where NULL is not zero?[/color]
>
> 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>).[/color]

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.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

pm940@yahoo.com wrote:[color=blue]
> 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.[/color]

It is *not* "obviously a bad thing". The C standard guarantees this
will work as the coder expected.
[color=blue]
> Can anybody provide specific examples of modern machines/systems be
> them embedded or supercomputer where NULL is not zero?[/color]

Since you are confused about what the implications might be, such a
discussion would be counterproductive.[color=blue]
>
> The standard says what the standard says and I don't want to debate it.[/color]

But you *should* learn what the standard says. Your "obviously a bad
thing" line shows that you don't yet have a clue.
[color=blue]
> Rather, I want to find counter-examples to prove that the standard's
> language still relevant.[/color]

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

pm940@yahoo.com writes:[color=blue]
> 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.[/color]

See section 5 of the C FAQ.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

pm940@yahoo.com wrote:[color=blue]
> p = malloc(...);
> if (!p)
> fail.
> Which is obviously a bad thing on non-zero NULL machines.[/color]

Artie Gold wrote:[color=blue]
> No, not at all.[/color]

Gordon Burditt wrote:[color=blue]
> No, it is *NOT* obviously a bad thing.[/color]

Chris Torek wrote:[color=blue]
> This is fine on "non-zero NULL machines".[/color]

Martin Ambuhl wrote:[color=blue]
> It is *not* "obviously a bad thing".[/color]

Keith Thompson wrote:[color=blue]
> See section 5 of the C FAQ.[/color]

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:
[color=blue]
> Your "obviously a bad thing" line shows that you don't yet have a clue.[/color]

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...?".

In article <Inyvn8.Fs6@cwi.nl> Dik T. Winter <Dik.Winter@cwi.nl> wrote:[color=blue]
>Did not the Data General MV series have null-pointers with the ring
>number embedded in the upper four bits?[/color]

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.
[color=blue]
>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.[/color]

I only ever wrote user-mode code on ours.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

In article <1128667282.703510.40300@z14g2000cwz.googlegroups. com>
<pm940@yahoo.com> wrote:[color=blue]
>P.S. Chris: "modern is 'anything made since 1965'" made me laugh...
>well, chuckle... ok it made me smile. I like playing "remember
>when...?".[/color]

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.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

In article <1128645954.797174.140400@g43g2000cwa.googlegroups .com>,
pm940@yahoo.com wrote:
[color=blue]
> 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.[/color]

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 [i] != 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.

Christian Bau <christian.bau@cbau.freeserve.co.uk> writes:
[color=blue]
> 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.[/color]

(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.

In article <di56v5017bt@news3.newsguy.com>,
Chris Torek <nospam@torek.net> wrote:[color=blue]
>I was thinking about some of the remarks about computers today
>compared to the ones available however-many years ago:[/color]
[color=blue]
> "Back in my day, we didn't have any fancy graphics, our
> characters were in ROMs!"[/color]
[color=blue]
> "You had ROMs? We had to work with discrete logic, all zeros
> and ones!"[/color]
[color=blue]
> "Ones? You had ONES?!"[/color]

Ah, but the analog computers didn't -have- ones! ;-)
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

Christian Bau wrote:[color=blue]
> In article <1128645954.797174.140400@g43g2000cwa.googlegroups .com>,
> pm940@yahoo.com wrote:
>
>[color=green]
>>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.[/color]
>
>
> 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.
>[/color]
Yes. "By definition" is the appropriate phrase here.
[color=blue]
> 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?[/color]

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.
[color=blue]
> 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.
>[/color]
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.
[color=blue]
> 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.
>[/color]
<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.

In article <kfnll15sj8s.fsf@alumnus.caltech.edu>,
Tim Rentsch <txr@alumnus.caltech.edu> wrote:
[color=blue]
> Christian Bau <christian.bau@cbau.freeserve.co.uk> writes:
>[color=green]
> > 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.[/color]
>
> (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.[/color]

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;

Christian Bau <christian.bau@cbau.freeserve.co.uk> writes:
[color=blue]
> In article <kfnll15sj8s.fsf@alumnus.caltech.edu>,
> Tim Rentsch <txr@alumnus.caltech.edu> wrote:
>[color=green]
> > Christian Bau <christian.bau@cbau.freeserve.co.uk> writes:
> >[color=darkred]
> > > 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.[/color]
> >
> > (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.[/color]
>
> 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.[/color]

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.

On 6 Oct 2005 18:32:07 -0700, pm940@yahoo.com wrote:

[color=blue]
>
>Chris Torek wrote:[color=green]
>> Define "modern".[/color]
>
>
>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.[/color]

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

--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up

Kevin D. Quitt <KQuitt@IEEInc.com> writes:[color=blue]
> On 6 Oct 2005 18:32:07 -0700, pm940@yahoo.com wrote:[color=green]
>>
>>Chris Torek wrote:[color=darkred]
>>> Define "modern".[/color]
>>
>>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.[/color]
>
> How about every x86 machine, where there's a segment and offset, and
> only the offset need be zero for NULL.[/color]

But the value of a null pointer (which is unique for each pointer
type) could still be, and probably is, all-bits-zero.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

In article <di4hqj02r8i@news2.newsguy.com>,
Chris Torek <nospam@torek.net> wrote:
[color=blue][color=green]
>>Can anybody provide specific examples of modern machines/systems be
>>them embedded or supercomputer where NULL is not zero?[/color][/color]
[color=blue]
>Define "modern".[/color]

Flat address space, uniform pointer representations, null pointer
is all-bits zero...

-- Richard

Keith Thompson <kst-u@mib.org> writes:
[color=blue]
> Kevin D. Quitt <KQuitt@IEEInc.com> writes:[color=green]
> > On 6 Oct 2005 18:32:07 -0700, pm940@yahoo.com wrote:[color=darkred]
> >>
> >>Chris Torek wrote:
> >>> 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.[/color]
> >
> > How about every x86 machine, where there's a segment and offset, and
> > only the offset need be zero for NULL.[/color]
>
> But the value of a null pointer (which is unique for each pointer
> type) could still be, and probably is, all-bits-zero.[/color]

I'm not aware of any language in the Standard that requires
that two null pointers of the same type must have the same
bit-for-bit values, only that they must compare equal. Can
you give a citation?

Tim Rentsch <txr@alumnus.caltech.edu> writes:[color=blue]
> Keith Thompson <kst-u@mib.org> writes:[color=green]
>> Kevin D. Quitt <KQuitt@IEEInc.com> writes:[color=darkred]
>> > On 6 Oct 2005 18:32:07 -0700, pm940@yahoo.com wrote:
>> >>Chris Torek wrote:
>> >>> 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.
>> >
>> > How about every x86 machine, where there's a segment and offset, and
>> > only the offset need be zero for NULL.[/color]
>>
>> But the value of a null pointer (which is unique for each pointer
>> type) could still be, and probably is, all-bits-zero.[/color]
>
> I'm not aware of any language in the Standard that requires
> that two null pointers of the same type must have the same
> bit-for-bit values, only that they must compare equal. Can
> you give a citation?[/color]

You're right. I'd say that all null pointers of a given type have the
same value, but not necessarily the same representation.

If there's more than one representation for a null pointer, the
generated code for a pointer equality comparison has to do more (or
less) than just comparing the bits.

On the other hand, the implementation could just pick a single
representation (say, all-bits-zero) and define that as the single null
pointer representation. As long as the other possible representations
are never generated by code that doesn't invoke undefined behavior,
everything should still be consistent.

In the real world, do x86 compilers really treat more than one
representation as equal to NULL?

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[snips]

On Wed, 12 Oct 2005 09:49:29 GMT, Keith Thompson wrote:
[color=blue]
> In the real world, do x86 compilers really treat more than one
> representation as equal to NULL?[/color]

Yes and no. It is possible to get "short pointers" (16-bit) in different
segments (so ds:offset, es:offset, etc) which can be problematic, insofar
as "full" comparisons of the 32-bit values may be necessary, may fail, yet
both will happily compare to NULL (since, by default, only the offset is
considered), and which have yet another problem when being compared to an
absolute address 0 (eg segment 0, offset 0).

That said, in order to get into such a mess, you have to be doing things
beyond the scope of what C actually does.

However...

It is remotely possible to get into a slightly related situation, where
pointers are treated by default as full 32-bit integers - but because of
oddities in addressing, each machine address can be represented by
something like 16 unique segment:offset pairs, hence 16 different integer
values.

Compilers which support this mode generally also produce normalizing code
for pointer operations such that comparing pointers can be done sensibly,
but this obviously has something of an impact on performance, so if you
need to work in modes such as this, the norm is to disable the
normalization for pointers involved in performance-sensitive areas and
normalize yourself when and as needed, rather than continuously.

Again, if you need to know this, you're well into non-standard-C-land, so
it's not really much of an issue - but it can potentially cause problems if
a library isn't expecting normalized pointers and thus doesn't do the right
thing, or, conversely, is expecting them but not getting them.

The short answer to the question, though, at least as far as conforming C
code is concerned, is no.

On 11 Oct 2005 21:36:39 GMT, richard@cogsci.ed.ac.uk (Richard Tobin) wrote:

[color=blue]
>In article <di4hqj02r8i@news2.newsguy.com>,
>Chris Torek <nospam@torek.net> wrote:
>[color=green][color=darkred]
>>>Can anybody provide specific examples of modern machines/systems be
>>>them embedded or supercomputer where NULL is not zero?[/color][/color]
>[color=green]
>>Define "modern".[/color]
>
>Flat address space, uniform pointer representations, null pointer
>is all-bits zero...[/color]

"The Circle is complete." -- Darth Vader

--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up

References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

re: References for machines where NULL is not zero.

/bytes/development

/bytes/it

/bytes/about