Re: NULL with representation other then all bits 0

In article <1138455155.362274.268670@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
yossi.kreinin@xxxxxxxxx wrote:

> Hi!
>
> There is a system where 0x0 is a valid address, but 0xffffffff isn't.
> How can null pointers be treated by a compiler (besides the typical
> "solution" of still using 0x0 for "null")?
>
> - AFAIK C allows "null pointers" to be represented differently then
> "all bits 0". Is this correct?
> - AFAIK I can't `#define NULL 0x10000' since `void* p=0;' should work
> just like `void* p=NULL'. Is this correct?
> - AFAIK I can identify contexts where `0' is used as a pointer and use
> the numeric value 0xffffffff rather then 0x0. Is this correct? In
> particular, should `void* p;' initialize p to "null pointer" rather
> then "zero" (so it has to be placed in ".data" rather then ".bss" in
> terms of typical implementations if "null pointer" is not represented
> as all bits 0)? Worse, should `memset(&p, 0, sizeof(void*))' set p to
> the "null pointer" rather then "zero"? Should casts from int to void*
> convert (int)0 (bits: 0x0) to (void*)0 (bits: 0xffffffff)?
>
> I know that this topic has been discussed a lot. That's even one of the
> reasons I'm not sure what the real answers are - I remember too many of
> them and can't tell the right ones from the wrong ones...

All your compiler has to do is to make sure that a cast from an integer
zero to a pointer type produces a null pointer, and a cast from a null
pointer to an integer type produces an integer zero.

If for example sizeof (int) == sizeof (void *), and a null pointer of
type (void *) has exactly the same representation as an int with a value
of 0x10000, then the cast from int to void* might translate to an "add"
instruction which adds 0x10000, and a cast from void* to int might
translate to a "subtract" instruction which subtracts 0x10000, or both
might translate to an "exclusive or" instruction which does an
exclusive-or with a value of 0x10000.

One other bit where the compiler must be careful: All static and extern
pointer variables without an explicit initialisation must be initialised
to a null pointer. Some compilers just produce code that sets everything
to zeroes and then fills in bits that are explicitely initialised; that
will not be enough if null pointers or floating point zeroes are not all
bits zeroes.
.

Relevant Pages

  • Re: Can I Trust Pointer Arithmetic In Re-Allocated Memory?
    ... You can't do pointer arithmetic on a void* value. ... qsort behaves in a manner consistent with its specification. ... actually works as advertised...but doesn't mean that the cast is ...
    (comp.lang.c)
  • Re: problem with memcpy and pointers/arrays confusion - again
    ... this second method is known as an explicit conversion, or cast. ... The cast, in effect, tells the compiler: ... the malloc function. ... function taking a size_t as a parameter and returning a void pointer (i.e. ...
    (comp.lang.c)
  • Re: dynamic_cast does not work as specified
    ... then p is a pointer to an object of type SubThing. ... SubThing* via a C-style cast. ... virtual void ShowPURE; ... type-id must be a derived class of expression [note that the simple explanation could be ...
    (microsoft.public.vc.mfc)
  • Re: [RFC] timers, pointers to functions and type safety
    ... * they have callback of type void ... callback is called by the code that even in theory has no ... cast to unsigned long and cast back in the callback. ... number - not a pointer cast to unsigned long, not an index in array, etc. ...
    (Linux-Kernel)
  • Re: is there a way to do this...
    ... >>void change ... i is a pointer to int, and on this platform, consumes a place in a ... This defines ptr to be a pointer to characters, ... the compiler intended us to go. ...
    (comp.lang.c)