volatile (in comp.lang.c)

[John R. Levine]

>In article <2114 at winchester.mips.COM> mash at winchester.UUCP (John Mashey) writes:
> [ "volatile" makes it possible to program memory-mapped devices in C,
> without having to resort to subterfuges like turning off the optimizer
> and hoping the compiler is dumb enough.  (I hope this doesn't misrepresent
> his argument.) ]

Nobody I know has argued that something like "volatile" isn't useful.
There's no doubt that it is.  The question is whether it belongs in ANSI C,
which purports to be a standard for a language for portable programs.

The problem is that volatile means many different things to different people.
For some people it means a memory-like device register.  For others, it means
shared memory that might be modified by another process, or memory that might
be modified by an interrupt routine or by the operating system.  Some
optimists even hope that something like this:

	extern volatile foo;
	...
	foo++;

could be used for synchronization of shared memory areas.

All of these are useful, and all of them are different. That's why a single
keyword in the language doesn't suffice to describe them. You'd have many
different implementations giving different semantics to the same syntax,
hardly a recipe for portability. Use a compiler-specific extension, or use a
#pragma. (I note in passing that for many architectures, if you're addressing
device registers you also need some way to tell the compiler to use aligned
16-bit references or some such, which clearly needs to be a #pragma.)

I suppose that if the C committee were prepared to decree a standard for the
semantics of shared variables, it would then be reasonable to define a keyword
to access them. Considering the plethora of shared memory implementations, and
the equally large plethora of synchronizing schemes, I doubt any such standard
would at this point be acceptable to more than a small minority of users.
Until then, though, let's restrict the standard language to things that we
know how to make portable.

To open another can of worms, this same argument applies to noalias.
-- 
John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869
{ ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine at YALE.something
Rome fell, Babylon fell, Scarsdale will have its turn.  -G. B. Shaw