Volatile is Necessary

[00704a-Liber]

In article <3113 at gryphon.CTS.COM> sarima at gryphon.CTS.COM (Stan Friesen) writes:
>In article <4192 at ihlpf.ATT.COM> nevin1 at ihlpf.UUCP (00704a-Liber,N.J.) writes:
>>  'Volatile', however, IS part of the
>>language specification.  I consider it to be a 'frill' because nothing else
>>in the language specification addresses hardware, per se.

>	But 'volatile' does NOT address *hardware*, it addresses asynchronous
>change is a value, which *may* be due to hardware, or to the execution of a
>logically asynchronous control thread(either a seperate process or a control
>thread in a single process such as a signal handler). It is needed often enough
>that I think it makes a meaningful addition to the language.

Ane I quote from section 3.5.3 of the standard:

	"Examples

	An object declared

		extern const volatile int real_time_clock;

	may be modifilable by hardware, but cannot be assigned to,
	incremented, or decremented."
	
	"[footnote] 52.  A volatile declaration may be used to describe an
	object corresponding to a memory-mapped input/output port or an
	object accessed by an asynchronously interrupting function. [...]"
	
Although what you say about asynchronous functions are true, I still
maintain that 'volatile' does indeed address hardware.  I do believe that
there is a need for a 'do_not_optimize' keyword (at least in non-strict
conforming programs); why call it volatile when we really mean
do_not_optimize??
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				"The secret compartment of my ring I fill
 /  / _ , __o  ____		 with an Underdog super-energy pill."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah