Ben Pfaff <[EMAIL PROTECTED]> writes: > This is a particularly pessimistic interpretation of the > standard,
You think _I'm_ pessimistic! You should hear Nick MacLaren and Dave Butenof. Here's a sample quote (in the threading area): ... the use of volatile accomplishes nothing but to prevent the compiler from making useful and desirable optimizations, providing no help whatsoever in making code "thread safe". Dave Butenhof, comp.programming.threads (1997-07-03) <http://groups.google.com/group/comp.programming.threads/msg/bd2cb64e70c9d155> > 5.1.2.3p5 talks about the type of an object, with no > reference to how the object was defined: > > The least requirements on a conforming implementation are: > > - At sequence points, volatile objects are stable in the > ^^^^^^^^^^^^^^^^ > sense that previous accesses are complete and subsequent > accesses have not yet occurred. As I understand it, under your interpretation this signal handler: #include <stdio.h> #include <signal.h> sig_atomic_t x; void handler (int sig) { sig_atomic_t volatile *p = &x; *p = 0; } int main (void) { signal (SIGINT, handler); x = 1; getchar (); return x; } always has well-defined behavior, since the signal handler simply stores 0 into a sig_atomic_t volatile object and it's immaterial how the object was defined. So if a signal arrives during the call to getchar, then 'main' must return 0 and not 1. But this interpretation doesn't correspond to how compilers behave. If the type sig_atomic_t is plain 'int', for example, a compiler is entitled to cache other references to x's contents even in the presence of signals. Both GCC and Sun C do this, e.g., on 64-bit SPARC they don't bother to set 'x' before getchar returns. More generally, I don't see how an object can be both volatile and nonvolatile at the same time: it has to be one or the other. Yet lvalues of both kinds can exist simultaneously. I suspect that I am simply misunderstanding your argument (which is not uncommon in this area!). If so, then if you could flesh out the argument a bit, that might help. (But I should warn you that I've never yet understood "volatile", despite my asking some very bright people what it actually means. :-) PS. MacLaren proposed a change to the C standard which would in his opinion fix some (but not all) of the problems with respect to signal handling and volatile; see <http://www.davros.org/c/public/pcuk0097.txt>. However, this proposal was not accepted. He later proposed something similar to the Open Group for Posix; see <http://www.opengroup.org/austin/mailarchives/ag/msg07173.html>. However, this proposal has been ignored by the Open Group as well. I suspect this is mainly because the problem area is just too hairy and that consensus cannot be achieved on what 'volatile' actually means.
