Path: utzoo!attcan!uunet!husc6!necntc!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.std.c
Subject: Re: volatile
Message-ID: <4053@haddock.ISC.COM>
Date: 17 May 88 19:37:26 GMT
References: <2642@geac.UUCP> <225800029@uxe.cso.uiuc.edu> <4727@ihlpf.ATT.COM> <5367@bloom-beacon.MIT.EDU> <4025@haddock.ISC.COM> <23502@pyramid.pyramid.com>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 17

In article <23502@pyramid.pyramid.com> cquenel@pyramid.UUCP writes:
>In article <4025@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes:
>>If |volatile| were removed, we'd either have to go back to the old rules
>>(everything's volatile) or absorb its meaning into |sig_atomic_t|.
>
>To the best of my knowledge, "volatile" is the only way of /guaranteeing/
>that a (for instance) local variable will NOT be restored/affected by a
>longjmp().

True.  In addition to absorbing its meaning into |sig_atomic_t|, we'd have to
add a guarantee that setjmp()/longjmp() will properly synchronize *all*
objects (which some of us think should be done anyway).

X3J11 vetoed this because it would setjmp() magic.  I expect that a proposal
to make sig_atomic_t magic would be even worse.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint