Clarification on type punning.

[Tom St Denis]

Really ?

I saw ton of code out there which uses pointer casts was used to
implement inheritance in C.

You can mimic the anonymous nature of C++ classes through the use of
structs with pointers to functions. I routinely use them in the
crypto code I write where, for instance, there is a struct which
defines a cipher interface, then the rest of my code calls the cipher
functions through pointers in the struct.

You really should have time when you need to cast from one non-void to
another non-void to do useful work. If anything you should convert
explicitly from one to another. for instance if you have

struct { int a; } ints;
struct { float a; } floats;

And you need to store floats in ints, just do a ints.a = floats.a;
Don't alias the pointers or whatever...

Tom

 

[Francis Moreau]

Conversion of a pointer to an struct into a pointer to the type of the
first member of that struct is guaranteed to result in a  pointer to
that first member (and vice versa). This is an example of type punning
that does have defined behavior.

Could you point out the revelant section in C99 where it's defined ?

Most possible uses don't, including
many that are very popular, and do in fact work as expected on the
platforms where they're used.

Ah, the only one I'm aware of and could use is the use case I showed
in my previous example.

Do you have any pointers where I could see the very popular ones ?

Thanks

 

[jameskuyper]

Could you point out the revelant section in C99 where it's defined ?

6.7.2.1p13: "A pointer to a structure object, suitably converted,
points to its initial member (or if that member is a
bit-field, then to the unit in which it resides), and vice versa."

Ah, the only one I'm aware of and could use is the use case I showed
in my previous example.

Do you have any pointers where I could see the very popular ones ?

Popular unportable uses of type punning include things like the
following:

long lvar = 5;
int ivar = *(int*)&lvar;

On platforms where this works as expected, it treats the low-order
sizeof(int) bytes of lvar as if they were an integer. Unless the
author was expecting it to extract the high-order bytes, in which case
the set of "platforms where this works as expected" will be different;
that's part of the reason this is non-portable.

On other platforms it may do something quite different from either of
those two options, which is the rest of the reason why it's
unportable.

 

[Franck]

6.7.2.1p13: "A pointer to a structure object, suitably converted,
points to its initial member (or if that member is a
bit-field, then to the unit in which it resides), and vice versa."

Thank you James

 

[Tim Rentsch]

Type punning is both more AND less that what's done by a cast
operator.

It's more than what's done by a cast operator, because it's not
sufficient to convert a pointer of one type into a pointer of a
different type; it order for type punning to occur, the converted
pointer must then be dereferenced, which necessarily involves at least
one more operator.

Type punning is also less than what's done by the cast operator,
because most uses of the cast operator don't involve pointers at all,
and even the ones that do aren't necessarily part of a type-pun.

Type punning can also be done by other methods, most notably by the
mis-use of unions. It can also be done using implicit type conversions
through void*, with not a single cast operator involved.

Type punning can also be done by the use of unions.
The main difference, type punning by means of
converting the address of a type-punned object is
almost always undefined behavior, whereas using
unions isn't.