dereferencing type-punned pointer, redux

[David Mathog]

We've established that a line of code like:

(void) function( (long *) &(something[i]) );

may (and probably should) generate one of these

warning: dereferencing type-punned pointer will break
strict-aliasing rules

if "something" is of some other type, say "int".

Assume for the sake of argument that elsewhere in the program we have
established that sizeof(int)==sizeof(long), and so we know it is safe
in terms of bytes of storage to keep both int and long in "something".
Then this variant would eliminate the type-punned pointer warning:

int something[SIZE];
int itmp,i;
long ltmp;

/* set i, other code, then */
(void) function( &ltmp); /* expects (long *) argument */
something[i]=(int) ltmp;
I'm guessing that if the temporary variable was not used anywhere else,
then the compiler would usually be smart enough to eliminate it and to
generate code pretty much equivalent to the one that generates the
type punned warning, but it would not generate such a warning because
here the compiler knows what it can get away with to store a long into
the int array.

The question is, is there some other way, within the C language
standard, to inform the compiler which sorts of pointers are equivalent,
so that function() could store directly into something[i] without having
to pass it through a temporary variable?

Regards,

David Mathog

[Eric Sosman]

David Mathog wrote On 07/10/07 13:29,:

We've established that a line of code like:

(void) function( (long *) &(something[i]) );

may (and probably should) generate one of these

warning: dereferencing type-punned pointer will break
strict-aliasing rules

if "something" is of some other type, say "int".

Assume for the sake of argument that elsewhere in the program we have
established that sizeof(int)==sizeof(long), and so we know it is safe
in terms of bytes of storage to keep both int and long in "something".

On the DeathStation 9000, sizeof(int)==sizeof(long),
but ints are Big-Endian signed magnitude and longs are
Little-Endian ones' complement. (This applies to DS9K
units manufactured on odd-numbered days in months with
"R;" the specifications for other models may differ.)

That is, sizeof(int)==sizeof(long) is a pretty strong
hint that the two are the same "under the hood," but it's
only a hint and not something C guarantees. On many
systems sizeof(int)==sizeof(float); does the coincidence
of sizes imply interchangeability?

Then this variant would eliminate the type-punned pointer warning:

int something[SIZE];
int itmp,i;
long ltmp;

/* set i, other code, then */
(void) function( &ltmp); /* expects (long *) argument */
something[i]=(int) ltmp;
I'm guessing that if the temporary variable was not used anywhere else,
then the compiler would usually be smart enough to eliminate it and to
generate code pretty much equivalent to the one that generates the
type punned warning, but it would not generate such a warning because
here the compiler knows what it can get away with to store a long into
the int array.

Sounds like a remarkably smart compiler. Eliminating
a variable whose address is taken and passed to another
function seems pretty advanced.

The question is, is there some other way, within the C language
standard, to inform the compiler which sorts of pointers are equivalent,
so that function() could store directly into something[i] without having
to pass it through a temporary variable?

Yes! There is a perfectly safe, Standard-conforming,
100% guaranteed, pure-as-the-driven-snow way to tell the
compiler that it's all right to use a long*, or all right
to store into an int. In fact, there are two ways:

void function(long*);
long something[SIZE];
function(&something[i]);

and

void function(int*);
int something[SIZE];
function(&something[i]);

In other words: Rather than searching for a foolproof
way to lie to the compiler and never get caught (are there
any politicians in your family tree?), it is better to
make a clean breast and not lie at all. Or in still other
other words: If you are so all-fired certain that int and
long are equivalent, why insist on using both spellings
instead of settling on one or the other?

--
Er*********@sun.com