volatile (again?) (was: noalias comments to X3J11)

[00704a-Liber]

In article <12578 at brl-adm.ARPA> PEPRBV%CFAAMP.BITNET at husc6.harvard.EDU (Bob Babcock) writes:
>>`Volatile,' in particular, is a frill for
>>esoteric applications, and much better expressed by other
>>means.  Its chief virtue is that nearly everyone can forget
>>about it.

>What about an interrupt routine which receives control on a keyboard
>interrupt and sets a globally known flag.

This is not really legal within C, since you are not allowed to dereference
an absolute address (such as doing x = *NULL, where NULL == 0).  However,
because of the relationship between C and actual memory address, I can see
how you would want a 'consistent' way of declaring 'volatile' objects (even
though it is non-portable).

The arguments for and against this are very close to the arguments for and
against a portable asm (actually, though, what was wanted was a CONSISTENT
way of declaring inline assembly code).  If ANSI is going to discuss
consistency of non-portable constructs, then volatile should still be
considered for ANSI C.  To be fair, though, all the other consistent
non-portable constructs should also be considered (a real BIG can of worms).


BTW, there already IS a semi-portable way of doing inline machine code.
Just look Sjoerd Mullender & Robert van Renesse's winning entry in the 1984
Obfuscated C Contest!!  :-) :-)
-- 
 _ __			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