unusual casting

[William S Fulton]

I'm looking for the name of the following casting style in order to do
some reading around on it and why it is sometimes used.

unsigned long long ull = 0;
void * ptr = 0;

ull = *(unsigned long long*)&ptr;

As opposed to the more usual casting:

ull = (unsigned long long)ptr;

I think it is just to silence compiler warnings, but if anyone has links
with further information, that would be great.

William

 

[Guest]

I'm looking for the name of the following casting style in order to do
some reading around on it and why it is sometimes used.

unsigned long long ull = 0;
void * ptr = 0;

ull = *(unsigned long long*)&ptr;

As opposed to the more usual casting:

ull = (unsigned long long)ptr;

I think it is just to silence compiler warnings, but if anyone has links
with further information, that would be great.

If you're dealing with code which is meant to be portable, simply don't
use the first form. The behaviour is undefined in standard C, and even
if unsigned long long is of the same size as void * and has no padding
bits, it will not do what's expected in some compilers (for example,
GCC).

Also, for the second form, using intptr_t or uintptr_t would be a
better idea if it's available. And when it's not available, unsigned
long long probably won't work either (but unsigned long might, if
you're dealing with C90).

 

[Keith Thompson]

I'm looking for the name of the following casting style in order to do
some reading around on it and why it is sometimes used.

unsigned long long ull = 0;
void * ptr = 0;

ull = *(unsigned long long*)&ptr;

As opposed to the more usual casting:

ull = (unsigned long long)ptr;

I think it is just to silence compiler warnings, but if anyone has links
with further information, that would be great.

Are you sure that's the actual code? It's treating an object of type
void* as if it were an object of type unsigned long long. There's no
reason to assume that they're going to be the same size.

 

[Walter Roberson]

Are you sure that's the actual code? It's treating an object of type
void* as if it were an object of type unsigned long long. There's no
reason to assume that they're going to be the same size.

Looks like a conflation of type-punning and the fact that pointers
can be converted to void* and back to the same type without any harm.

But the special properties of void* do not apply to pointers to
void* (i.e., void**), so converting that to unsigned long long*
is not certain to produce any kind of meaningful result -- and
the leading * dereferences the result, so it's trying to
get at an unsigned long long value in the space that is there for
a void* (a pointer), which is also pretty dubious. And it's doing
this for a NULL pointer, which isn't certain to have an all-zeros
representation. Perhaps someone's trying to test whether
the void* NULL pointer is in fact all zeros?? Not a particularily
useful test, since other NULL pointers might have different
internal values (as long as they -compare- properly.)

So I agree, the code is broken or else it doesn't actually look
exactly like that.

 

[William S Fulton]

Are you sure that's the actual code? It's treating an object of type
void* as if it were an object of type unsigned long long. There's no
reason to assume that they're going to be the same size.

The approach is used where the unsigned long long is a JNI jlong. So it
is a way of storing a C pointer in a Java long (an unsigned 64 bit
number on all platforms). Even if the void * is 32 bits, it still works,
as it gets cast back into a void * when passed from the Java layer to C
layer. Perl does the same thing converting between pointers and
integers. None of this is 100% portable in theory, but is in practice on
all the systems that support Perl and Java. That is if you aren't using
the latest gcc with optimisation turned on as the cast breaks aliasing
rules. The main problem is that C does not provide a 100% portable way
of casting a pointer into an integer and back again.

Still, that is a bit of digression and I am really looking to find out
if this type of casting has a name. I think I read a long time ago, it
was some sort of universal type of cast that would never fail to compile
on all systems, or something like.

William

 

[Keith Thompson]

Please don't send me e-mail copies of Usenet followups.

[...]

Still, that is a bit of digression and I am really looking to find out
if this type of casting has a name. I think I read a long time ago, it
was some sort of universal type of cast that would never fail to compile
on all systems, or something like.

It's a form of type punning, i.e., pretending that an object (memory
region) holding something of one type holds a value of a different
type.

The difference between
ull = *(unsigned long long*)&ptr;
and
ull = (unsigned long long)ptr;
is that the first pretends that the object ptr holds a value of type
unsigned long long, whereas the second *converts* the value of ptr
(which is of type void*) to unsigned long long. A conversion from a
pointer type to an integer type is implementation-defined; it may just
reinterpret the same bit pattern, or it may perform some non-trivial
conversion (as conversions between integers and floats do). On *most*
systems, conversion between a pointer and an integer *of the same
size* just copies the bits.

Note that if, for example, void* is 32 bits and unsigned long long is
64 bits, the statement
ull = *(unsigned long long*)&ptr;
attempts to read 64 bits from a 32-bit object. This invokes undefined
behavior; most likely, ull will contain 32 bits from the pointer
object and another 32 bits of whatever garbage happened to be stored
next to it. And these could be in either order. On the other hand,
converting from void* to unsigned long long, though it's
implementation-defined doesn't attempt to read garbage. Most likely
(if sizeof(unsigned long long) > sizeof(void*)) it will just copy the
bits of the pointer and zero-extend the result.

 

[riedel]

The approach is used where the unsigned long long is a JNI jlong. So it
is a way of storing a C pointer in a Java long (an unsigned 64 bit
number on all platforms).

William

pedantic:
the only unsigned Java type is char (which is not a C char).

Wolfgang

 

[William S Fulton]

pedantic:
the only unsigned Java type is char (which is not a C char).

Yeah, sorry, that was a typo and should read 'signed 64 bit number'.

William