Type-punning and aliasing

[bearophile]

A short but nice article I've found through Reddit:
http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing/

http://www.reddit.com/r/programming/comments/hwdyk/real_examples_in_qt_where_bugs_where_caused_by/

Quotations from the article:

>        int i = 42;
>        short s = *(short*)&i;
>
> The above will probably work (emphasis on probably), but the results are undefined.
> That means the compiler is free to do anything, like emailing your boss about this
> transgression. But even without the strict-aliasing rule, the code above still has no
> defined behaviour, as it has two possible results: 0 or 42, depending on the endianness.

I guess this code is equally undefined in D.


> This also applies to the code:
>         union {
>                 int i;
>                 short s;
>         } u;
>         u.i = 42;
>         u.s = 1;
>         printf("%d\n", u.i);
> 
> The behaviour above is undefined according to the C standard. It is, however,
> accepted by GCC (it prints 1 on x86) -- but not by other compilers.

Maybe this code too is undefined in D. But I have seen similar D code in the wild.

In several situations I think @safe is not enough, in a system language you want to do certain unsafe things, so allowing them just in some parts of your programs doesn't save you from bugs. I'd like to be a bit safer in @system modules too :-)

There is a possible solution for the endianess. I have faced this problem a bit in the last suggestion for the bitfields:
http://d.puremagic.com/issues/show_bug.cgi?id=4425

I think endianess problems go away if your type system forces you to put endian-sensible lines of code inside the then or else branches of a static if (std.system.endian==std.system.Endian.BigEndian) statement :-) This makes the @system code too safer.

Bye,
bearophile