0 Members and 1 Guest are viewing this topic.
I've decided not to fix bugs involving strict-aliasing, because it's justtoo much of a hassle. I'll take patches from other people, but I can'tguarantee that I won't break them again, because strict-aliasingoptimizations break too many traditional C programming practicesand in fact make one standard technique I use impossible (I think;I posted some suggestions on molly rocket for how it might be tackledin the image writing library, but I don't know if they'll actually work--basedon past experience probably not).Anyway, I can't test it myself because I don't have a gcc install set upright now and it's only gcc that does this, and I don't really want to puteffort into setting it up and testing it, because:I think the gcc developers made a mistake with this; it is allowedby the C spec, but this is because the C specification is beingdeveloped by people who don't realize the consequences ofthis (those people are mostly compiler writers like the gcc authors)on the ability to write robust C code. No compilers other than gcc dothis (and supposedly Apple turned it off in the gcc that ships withtheir OS).A summary of issues with strict aliasing explaining why we don'tuse it at the place where I work:http://robertoconcerto.blogspot.com/2010/10/strict-aliasing.htmlLinus Torvalds explaining why they use -fno-strict-aliasing in theLinux kernel:http://lkml.org/lkml/2003/2/26/158A more general analysis of the problem with compilers gong too far:http://www.securecoding.cert.org/confluence/download/attachments/26017980/SD+West+Dangerous+Optimizations.pdf?version=1