Oppolzer - Informatik / Blog

Sorry for jumping late into this thread.

After reading all this posts, my impression is that it's all about optimization.
Due to the ANSIALIAS option being in effect (or what else it is called in the
non-IBM compilers), the compiler thinks that the casted pointer of type unsigned
short * and the object it references never may have anything to do with the
unsigned long variable called a, since it has an incompatible type - so the
compilers throws away the third line completely, because it does not have any
effect on the known variables (there is only a, in fact).

This is not an error, but correct behaviour, given the meaning of the ANSIALIAS
option and the optimization strategy of the compiler. For us human readers it is
obvious that the third line relates to the variable a; for the compiler it is
not.

I have some programs, too, where I think such optimization would break the
logic, so I would not set such an option without careful tests. Furthermore I am
working for a company where we have a large math package written in C, and the
build process of the package is centralized, that is, there are standard options
for the compiles for all components. I'm doing some consulting there, and I
would not accept such an option at the moment, because I'm almost sure that we
have some functions there which would not work, given such optimizations. It
would be a project of medium to large size to make our code tolerant for such an
option. I'd compare this to the effort we did some years ago to run our code on
64 bit platforms.

Thank you all for this discussion. A happy new year to you all.

Kind regards

Bernd




Am 03.01.2014 22:10, schrieb D.T.:
>
>     #include <stdio.h>
>     #include <stdlib.h>
>
>     #ifdef WORDS_BIGENDIAN
>     #define I 1
>     #else
>     #define I 0
>     #endif
>
>     void main()
>     {
>        unsigned long a;
>        a = 111;
>        *((unsigned short*)&a + I) = 222;
>        printf("a = %d\n",a);
>     }
>
>