chris@mimsy.UUCP (Chris Torek) (01/06/89)
>In article <15304@mimsy.UUCP> I noted >>For portable code, you must avoid `register volatile', because current >>systems (not dpANS-conformant, but still useful, such as SunOS) will >>use something like >> #define volatile /*empty*/ In article <9290@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >But that's clearly wrong in the first place. When back-porting to a >pre-ANSI C environment, all uses of "volatile" (there shouldn't be >many) have to be carefully checked to determine just why "volatile" >was necessary, and adjustments made (if possible). There is no viable >alternative! 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. Presumably this (that is, using no qualifier at all) already works in all existing applications that use setjmp, since there is in fact no alternative at all. ----- % Well, the only one I can think of. ----- >P.S. I do plant the above definition in pre-ANSI C environments A-*ha*! :-) >(although I can't recall using it), but I don't expect it to "do the >right thing" automatically, because it can't. *Nothing* can; that is the point: so we use nothing. (That was a joke.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/07/89)
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.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/07/89)
In article <9300@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >I think that's the only PORTABLE use, but certainly a standard- >conforming program CAN use the "volatile" type qualifier in other >(nonportable) contexts. It occurs to me that I may not have made this clear enough. A portable, standard-conforming program does not become nonportable or non-conforming upon addition of "volatile" qualifiers (assuming of course the addition is done according to the type rules). It is only the actual reliance upon the property of volatility that would be nonportable. (e.g. device register) int main() { volatile int i; return i = 0; } is a portable, standard-conforming program.
friedl@vsi.COM (Stephen J. Friedl) (01/08/89)
In article <9302@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes: > > It occurs to me that I may not have made this clear enough. > A portable, standard-conforming program does not become nonportable > or non-conforming upon addition of [feature of ANSI C]. One might point out here that "portable" and "standard-conforming" are not necessary the same thing. Many of us will have to deal with pre-ANS compilers for a very long time, and "complaining to our vendor" will do as much good as complaining to our Congressman. Steve -- Stephen J. Friedl 3B2-kind-of-guy friedl@vsi.com V-Systems, Inc. I speak for me only attmail!vsi!friedl Santa Ana, CA USA +1 714 545 6442 {backbones}!vsi!friedl -------Nancy Reagan on Usenix in San Diego: "Just say *go*"-------