volatile

[Doug Gwyn]

In article <1011 at ima.ISC.COM> johnl at ima.UUCP (John R. Levine) writes:
>The standard defines a language for writing portable programs, i.e.
>any standard-conforming program should do the same thing on all ANSI C
>processors.

This simply isn't true.  Since this is explained on p.4 of the draft
proposed Standard, and the remarks about "volatile" are completely
wrong, one has to conclude that this fellow has decided to explain
the proposed Standard to you all without having understood it himself.

There are two forms of Standard-conforming implementations (hosted
and freestanding) and two forms of compliance for programs (conforming
and strictly conforming).  Conforming programs need not be at all
portable; they merely need to be acceptable to a conforming
implementation.  In particular, conforming programs may be utterly
dependent on implementation-specific features.

>I have never seen any suggestion that a program containing
>"volatile" would be portable except perhaps to other processors which happen
>to have similar memory, I/O, and hardware architectures.

The following program is strictly conforming (i.e. portable):

#include <stdio.h>
main()	{
	volatile int i;
	for ( i = 0; i < 10; ++i )
		printf( "%d\n", i );
	}

It is not the use of the "volatile" type qualifier that makes a program
non-portable, but rather dependence on characteristics not guaranteed
by the language specification.

>So, sure, go ahead and put it in your compiler where it will be useful for
>all sorts of stuff.  But keep it out of the standard until you can define it
>in a way that will produce the same results on all C processors.

The whole purpose of "volatile" is to provide a well-defined method
to obtain strict virtual machine semantics, as opposed to highly-
optimized "equivalent" semantics.  This is obviously more nearly
universal than almost anything else in the proposed Standard.
How you as a programmer choose to exploit this is up to you.