References for machines where NULL is not zero.

K

Keith Thompson

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

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

Richard Tobin

Can anybody provide specific examples of modern machines/systems be
them embedded or supercomputer where NULL is not zero?
[/QUOTE]
Define "modern".

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

-- Richard
 
T

Tim Rentsch

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

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?
 
K

Keith Thompson

Tim Rentsch said:
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?

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?
 
K

Kelsey Bjarnason

[snips]

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

Yes and no. It is possible to get "short pointers" (16-bit) in different
segments (so ds:eek:ffset, es:eek:ffset, 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:eek:ffset 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.
 
K

Kevin D. Quitt

Define "modern".

Flat address space, uniform pointer representations, null pointer
is all-bits zero...[/QUOTE]

"The Circle is complete." -- Darth Vader
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,169
Messages
2,570,920
Members
47,464
Latest member
Bobbylenly

Latest Threads

Top