Don Davis writes: * the c99 standard and its predecessors don't at all intend "volatile" to mean what we naively think it means. specifically, in the hands of a high-end compiler developer, the spec's statement: "any expression referring to [a volatile] object shall be evaluated strictly according to the rules of the abstract machine" is really talking about what the compiler can infer about the program's intended semantics. a c99-compliant compiler _can_ legitimately remove a volatile access, as long as the compiler can deduce that the removal won't affect the "program's result."
Sorry, but that is really not correct at all. "volatile" exists because there are times when you absolutely need to know that the compiler will not alter your intent. A typical example is in touching a device register in a device driver. You may very well need to write a certain set of values out to a particular memory location in a particular order and not have them optimized away or reorganized. It may be vitally important to access register 2 and then register 1, or to write multiple values out to register 4 before touching register 3, or what have you. In a driver or in a situation like this you really do mean "write a one there and then write a ten there and never mind that you think you can optimize away writing the one there." "volatile" means that the memory location has side effects and that you CANNOT deduce the result of the operations and thus are required to not touch the sequence at all. The spec specifically states that you may NOT remove or reorder sequence points if "volatile" is in use. That is why "volatile" exists. It means "do NOT reorder or eliminate access to these memory locations on pain of death". The intent of the spec is precisely what I've said, and I'll happily quote chapter and verse to prove it. There are several similar misconceptions about the "volatile" keyword that have been propagated in recent messages. Claims that "volatile" does not guarantee a safeguard against such optimizations are specious. That is exactly why "volatile" was introduced, and if, for example, gcc did not honor it, the machine I am typing at right now would not work because the device drivers would not work. Any optimizing compiler that people write device drivers in practically *has* to support "volatile" or it won't work for that purpose. (In the days before "volatile" you needed vile tricks to assure your intent was followed, or you needed to not optimize driver code, or both.) Some have claimed "volatile is not a mandatory part of C". Well, it is certainly mandatory in the C standards I have at hand. C99 makes it abundantly clear that you have to do it and do it correctly. Some have claimed "you can't know that the compiler writer implemented volatile correctly so you need a #pragma". Well, that doesn't actually help you. If they haven't implemented "volatile" right, why should they implement the pragma correctly? We already have a way of indicating "do not reorder or eliminate this code" which is in existing standards -- if it doesn't work, that's a bug in your compiler, and it is better to get the bug fixed than to ask for another feature to be added that might also be buggy and which is not part of the standard. So in short, yes, "volatile" might be implemented in a buggy way by your compiler (which you should certainly test for if it is important to you!) but if your compiler is in fact properly implemented and standards compliant, "volatile" is the way to accomplish what you are trying to accomplish here. -- Perry E. Metzger [EMAIL PROTECTED] --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]