Does pointer assignment preserve bit pattern?

[Ian Pilcher]

The more I think about pointers, the more my head hurts.

From what I can tell, nothing in the standard guarantees that pointer
assignment preserves bit patterns.

Section 6.5.16.1, paragraph 2, states:

In simple assignment (=), the value of the right operand is
converted to the type of the assignment expression and replaces
the value stored in the object designated by the left operand.

Since we know that multiple bit patterns can represent the same "value",
it's possible that the following function could return a non-zero value.

int ptr_test(void)
{
char c;
void *p, *q;

p = &c;
q = p;

return memcmp(&p, &q, sizeof(void *));
}

Since I know you'll ask, I was thinking about implementing some simple
functions modeled after Win32's HeapAlloc, HeapFree, etc. A "heap" in
this case would just be a binary search tree, using the pointers
returned by malloc (or calloc or realloc) as keys.

This won't work, though, if I can't somehow compare pointers to
different objects, which rules out a simple comparison.

Am I missing something?

Thanks!

 

[Kevin Easton]

The more I think about pointers, the more my head hurts.

From what I can tell, nothing in the standard guarantees that pointer
assignment preserves bit patterns.

Section 6.5.16.1, paragraph 2, states:

In simple assignment (=), the value of the right operand is
converted to the type of the assignment expression and replaces
the value stored in the object designated by the left operand.

Since we know that multiple bit patterns can represent the same "value",
it's possible that the following function could return a non-zero value.

int ptr_test(void)
{
char c;
void *p, *q;

p = &c;
q = p;

return memcmp(&p, &q, sizeof(void *));
}

Since I know you'll ask, I was thinking about implementing some simple
functions modeled after Win32's HeapAlloc, HeapFree, etc. A "heap" in
this case would just be a binary search tree, using the pointers
returned by malloc (or calloc or realloc) as keys.

This won't work, though, if I can't somehow compare pointers to
different objects, which rules out a simple comparison.

Am I missing something?

You can compare pointers to different objects - a pointer to an object
is guaranteed to compare unequal to a pointer to any other object, and
unequal to NULL.

What you can't do is use (in comparisons, or otherwise) pointer values
that are indeterminate - ones that *don't* point to an object.

You can almost certainly do what you need by setting any pointer object
that holds an indeterminate value (eg. after its value has been freed)
to NULL.

- Kevin.

 

[Ian Pilcher]

You can compare pointers to different objects - a pointer to an object
is guaranteed to compare unequal to a pointer to any other object, and
unequal to NULL.

Yes, but I need to establish a consistent sorting order, and using
relational operators with pointers to different objects is UB.

This led me to consider using memcmp, but memcmp won't necessarily be
reliable if pointer assignment isn't guaranteed to preserve bit
patterns.

 

[E. Robert Tisdale]

The more I think about pointers, the more my head hurts.

From what I can tell, nothing in the standard guarantees that pointer
assignment preserves bit patterns.

Section 6.5.16.1, paragraph 2, states:

In simple assignment (=), the value of the right operand is
converted to the type of the assignment expression and replaces
the value stored in the object designated by the left operand.

Since we know that multiple bit patterns can represent the same "value",
it's possible that the following function could return a non-zero value.

int ptr_test(void) {
char c;
void *p, *q;

p = &c;
q = p;

return memcmp(&p, &q, sizeof(void *));
}

Since I know you'll ask, I was thinking about implementing some simple
functions modeled after Win32's HeapAlloc, HeapFree, etc. A "heap" in
this case would just be a binary search tree, using the pointers
returned by malloc (or calloc or realloc) as keys.

This won't work, though, if I can't somehow compare pointers to
different objects, which rules out a simple comparison.

Am I missing something?

Thanks!

If q = p then (q == p) is true and (q != p) if false.
There are also two zeros in almost all floating-point representations.

(-0.0 == +0.0) is true.

 

[Alf P. Steinbach]

[Crossposted - added comp.lang.c++ to the group list]

Yes, but I need to establish a consistent sorting order, and using
relational operators with pointers to different objects is UB.

In C, yes, as far as I know.

In C++ that (you can't compare pointers in general wrt. order) is also
true at the language level, but not at the standard library level.

So perhaps -- switch to C++?

 

[Dan Pop]

Pointer assignment preserves all _value_ bit values, assuming the
assignment is between pointers to the same type.

Chapter and verse, please. Where does the standard say that each
address is guaranteed to have a unique representation (in terms of value
bits)?

Dan

 

[Dan Pop]

The more I think about pointers, the more my head hurts.

From what I can tell, nothing in the standard guarantees that pointer
assignment preserves bit patterns.

This is correct. The same address (pointer value) can have multiple
representations (as many as 4096 in the case of the 8086).

Then again, pointers can have padding bits, although the standard
doesn't explicitly say so. Pointer assignment need not replicate them.

OTOH, the standard guarantees that copying the representation also copies
the value, so, if this is important to you, you can use memcpy instead of
pointer assignment.

Dan