Peter Gutmann writes:
"James A. Donald" <jamesd@echeque.com> writes:
If the optimizer ever optimizes away a write to volatile memory, device drivers will fail. Most device drivers are written in C. If anyone ever produces a C compiler in which "volatile" does not do what we want, not only are they out of spec, but smoke will start coming out of hardware when the device drivers are recompiled.
The people who assume that any compiler which compiles their code gets an obscure feature like volatile exactly as per the spec are probably the same ones who assume that fixed-size buffers will never be exceeded.
I don't understand this extraordinary level of concern As both James and Perry have tried to point out, 'volatile' is *not* an obscure feature. Maybe it was obscure back in the mid-1980s, but every C compiler I've seen in years supports volatile. Its behavior has been part of the C std for a long time now, and it's a critical part of a large body of code on pretty much every platform. It's interesting that you bring up the subject of "fixed size buffers" being overrun. That also results from ignorance and carelessness on the programmer's part *not* from incorrect compiler implementation.
It's my job to be paranoid. I will assume that an arbitrary compiler gets a while() loop right (it'd be obvious if it didn't), but I won't gamble my crypto keys over assumptions about the correct handling of volatile in all compilers.
It sounds like the problem is more a lack of understanding of what 'volatile' means. Nowhere in this thread (or from what I can tell, the thread on vuln-dev) has anyone alleged that an actual compiler didn't handle 'volatile' correctly. - GH _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail