build: resolve compiler warnings

[jengelh]

modules/swfaction.c:434:6: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] printf(" Float:%f", (float)&f); modules/swfaction.c:455:6: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] printf(" double:%f", (double)a); modules/swfaction.c: In function 'action_GotoFrame': modules/swfaction.c:927:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] (U16)atag->tmp = LE_16_TO_NATIVE(frame); modules/swfaction.c: In function 'action_Jump': modules/swfaction.c:934:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] (U16)atag->tmp = LE_16_TO_NATIVE(branch); modules/swfaction.c: In function 'action_If': modules/swfaction.c:940:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] (U16)atag->tmp = LE_16_TO_NATIVE(branch); modules/swfaction.c: In function 'action_WaitForFrame': modules/swfaction.c:970:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] (U16)atag->tmp = LE_16_TO_NATIVE(frame); modules/swfaction.c: In function 'action_PushFloat': modules/swfaction.c:1031:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] U32 fd = (U32)&f;

[matthiaskramm]

Are these the only warnings of this kind? I would have thought that we have code like this in other places, too.

The memcpy approach looks a bit clunky. Is that the best fix?

[jengelh]

Are these the only warnings of this kind?

Haven't seen any other strict-aliasing ones. The pattern does repeat, e.g. at (U8)x = y;, but U8 being char always satisfies alignment requirements.

The memcpy approach looks a bit clunky. Is that the best fix?

It certainly is an appropriate fix. One of the operands may not be suitably aligned (like when copying between double and two U32s), so it has to be byte-copied, which memcpy does. Or the memcpy implementation does something better, hardware permitting. So yes, I believe it to be the best fix from where I stand.

[matthiaskramm]

lib/types.h defines PUT8 / PUT16 / PUT32. Would those work as well?

[jengelh]

They would. Seems like they also handle the little/big endian conversion, so I'd say go for it.

[lieff]

Put* not enough for portable float conversion. There at least 3 existing double layouts. Here code with run-time detection https://github.com/lieff/lvg/blob/master/swf/avm1.c (read_double and read_float).

[matthiaskramm]

"Word swapped little endian host". Huh. I guess we should add the float equivalent of PUT64 / GET64.