Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: #define volatile /*empty*/
Message-ID: <9300@smoke.BRL.MIL>
Date: 7 Jan 89 01:22:10 GMT
References: <141@bms-at.UUCP> <275@twwells.uucp> <15166@mimsy.UUCP> <9290@smoke.BRL.MIL> <15318@mimsy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 19

In article <15318@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>But the only% use for volatile in conformant code, aside from any
>hidden under the `sig_atomic_t' typedef, is to protect against setjmp/
>longjmp interactions.

I think that's the only PORTABLE use, but certainly a standard-
conforming program CAN use the "volatile" type qualifier in other
(nonportable) contexts.

Not to imply that you think this, but it may be worth pointing out
that X3J11 did NOT have as one of its goals the easing of problems
when "back-porting" standard-conforming programs to non-standard C
environments (such as "K&R 1st Ed." C, whatever that is taken to
mean).  This is quite evident, but since some people have in the
past been confused about this point, I thought I'd mention it.
(It's the PRIME reason I object so strongly to non-conforming
environments defining __STDC__.  Without __STDC__ to key on, I
don't know how to write code that exploits much of that which is
new and useful in ANSI C yet still works on old PCC-based systems.