Path: utzoo!attcan!uunet!lll-winken!lll-lcc!pyramid!cquenel
From: cquenel@pyramid.pyramid.com (The Prince Who Was A Thousand)
Newsgroups: comp.std.c
Subject: Re: volatile
Message-ID: <23502@pyramid.pyramid.com>
Date: 17 May 88 01:26:47 GMT
References: <2642@geac.UUCP> <225800029@uxe.cso.uiuc.edu> <4727@ihlpf.ATT.COM> <5367@bloom-beacon.MIT.EDU> <4025@haddock.ISC.COM>
Reply-To: cquenel@pyramid.UUCP (The Prince Who Was A Thousand)
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 19

In article <4025@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes:
>
>There's a simpler refutation: the premise is false.  The signal() function is
>part of the standard library, and |volatile| is necessary for handlers of
>asynchronous signals.  Earlier I posted a strictly conforming program which
>contained some lines like:
>  #include <signal.h>
>  static volatile sig_atomic_t gotcha = 0;
>  static void catch(int signo) { gotcha = 1; }
>which argument has not been refuted to my knowledge.
>
>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().  According to the version of the standard I was browsing.

--chris