• bearophile (12/29) Jun 10 2011 A short but nice article I've found through Reddit:

bearophile <bearophileHUGS lycos.com> writes:

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