www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Type-punning and aliasing

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
Jun 10 2011