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

In article <5367@bloom-beacon.MIT.EDU> peter@athena.mit.edu (Peter J Desnoyers) writes:
>The debate over |volatile| seems to focus on one point: if this keyword is
>only necessary for non-portable code, why does it have to be part of the
>language?  [Goes on to discuss cross-compilers]

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|.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
Followups to comp.std.c.