Oppolzer - Informatik / Blog

another thought:

if you want to do such overlays with the ANSIALIAS option switched on, I believe
you can do it using unions.

That is, a union that contains both the unsigned long and the unsigned short
field, then you assign first the unsigned long 111, then the unsigned short 222,
then you print the unsigned long.

This way the compiler must generate code for both assignments, even if ANSIALIAS
is on. Because it is the same type of object (the union).

Of course, the outcome will depend upon the representation on the platform, for
example, endianness.

This, IMHO, is the way, to make your code ANSIALIAS-safe, while still being able
to do storage overlays. The pointers must be pointers to the unions, not
pointers to the components, and then the proper component is selected.

Kind regards

Bernd



Am 05.01.2014 10:18, schrieb Bernd Oppolzer:
> My opinion, which is somehow different:
>
> it's all about optimization.
>
> If we want the highest possible level of optimization,
> we must accept some comfort limitation on the compiler's
> (and programmer's) side. That's what the ANSIALIAS option
> is all about. This option tells the compiler that a pointer of type
> unsigned short never points to an object of type unsigned long,
> so the line which assigns the value 222 never may have an effect
> to the variable a. The compiler may assume this, when the
> ANSIALIAS option is in effect, and move the assignment anywhere
> out of the scope of the actual function to optimize the overall
> performance;
> in this case, the compiler is free to remove it completely, because this
> assignment has no effect to any known variable of type unsigned short.
> I believe that the compiler has no obligation to do further checks
> for the storage areas (if they overlay or not) in this case, although I too
> would suggest that it should produce a suitable warning.
>
> If you don't want this behaviour of the compiler, you simply don't use
> the ANSIALIAS (or similar) options - which I would do at least sometimes,
> by the way, because some of my programs also rely on such storage overlays.
>
> That means of course - and that's one of the things I've learned from this
> discussion: we may never test a function using - say - optimize level n and
> then move the function into production using optimize level n + 1 -
> untested!
>
> Kind regards
>
> Bernd
>
>