> In support of this, IĆ¢??d encourage everyone who works with C to read Chris $
> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html > http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html > http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html Reading this really gives me the impression that it's time to fork C. There seems to me to be a need for two different languages, which I might slightly inaccurately call the one C used to be and the one it has become (and is becoming). The first is the "high-level assembly" language, the one that's suitable for things like embedded programming in what C99 calls a standalone environment, kernel and low-level library implementations, and the like, where you want to do whatever's reasonable from the point of view of someone who knows the target machine architecture, even if it's formally undefined by the language. The second is more the language the author of those posts is talking about, where the compiler is allowed to do surprising things for the sake of performance. The zero_array example slightly bothers me, because the optimization into a memset is valid only when floating-point zero is all-bits-zero; while this is something the compiler can know, and is true on "all" machines, the way it's written doesn't call it out as a machine-dependent optimization, quite possibly leading people to write the memset themselves in such cases, producing a different bug. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B