Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-lcc!ames!husc6!uwvax!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: #define volatile /*empty*/ (was register volatile)
Message-ID: <15318@mimsy.UUCP>
Date: 6 Jan 89 11:49:39 GMT
References: <141@bms-at.UUCP> <275@twwells.uucp> <15166@mimsy.UUCP> <9290@smoke.BRL.MIL>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 35

>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