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
