Path: utzoo!mnetor!uunet!husc6!mailrus!ames!pacbell!att-ih!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.lang.c Subject: volatile (again?) (was: noalias comments to X3J11) Message-ID: <4188@ihlpf.ATT.COM> Date: 29 Mar 88 23:48:25 GMT References: <12578@brl-adm.ARPA> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 31 In article <12578@brl-adm.ARPA> PEPRBV%CFAAMP.BITNET@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." / (_