Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!polygen!pablo
From: pablo@polygen.uucp (Pablo Halpern)
Newsgroups: comp.lang.c
Subject: Re: Volatile is Necessary
Message-ID: <140@polygen.UUCP>
Date: 8 Apr 88 00:51:00 GMT
References: <102@obie.UUCP>
Organization: Polygen Corporation, Waltham, MA
Lines: 57

Sorry if you got this twice, but I think my original posting got lost ...

In article <1988Mar29.004454.2867@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>... The principal problem with #pragma
>is that it is not portable, since its semantics are not standardized, but
>the sort of code we're talking about isn't portable anyway.

Not true.  Volatile was invented to solve some of the problems associated
with multiprocessing or multitasking.  These problems surface even in
programs that do no interprocess communication if they use the signal()
fuction which exists in the standard library.  A signal handler is very
similar to a separate task that shares memory with the main-line program.
Any variable that might be changed by a signal handler should be declared
volatile since it may change at any time on receipt of a signal.  If
it is not declared volatile, the main-line program may continue to use
an old cached value long after the variable has changed, potentially
going into an endless loop waiting for it to change.  Similar situations
occure with setjmp()/longjmp().

From article <4192@ihlpf.ATT.COM>, by nevin1@ihlpf.ATT.COM (00704a-Liber):
> setjmp() is a function call (in much the same way as fork(), exec(),
> exit(), etc.) and is not part of the language specification itself (it is
> not in section 3 of the draft standard).  Same is true about side effects of
> functions of dangerous pointers.  'Volatile', however, IS part of the
> language specification.  I consider it to be a 'frill' because nothing else
> in the language specification addresses hardware, per se.

This is also true of signal() but without volatile, signal() could not
be written.  I see nothing wrong with having language features that support
the library definition.  After all, the purpose of this whole process is
to design a language that supports the writing of programs.

FLAME ON
	I'm also sick of people implying that any program that is not
	strictly conforming is totally non-portable.  I write a lot of
	programs that are portable to a large number of machines but
	are not portable to ALL machines.  I also write a lot of programs
	that have small, self-contained, sections that handle non-portable
	things like shared memory allocation, interupt handling, semaphores,
	etc..  Volatile would allow me to keep these sections small and
	isolated because the program could "admit" that it might be
	running in a multi-tasking environment.  As it is, I'm already
	playing it a bit dangerous when it comes to signal handlers.

	If volatile were a #pragma, then every compiler could choose its
	own syntax and semantics for it, if it were implemented at all.
	Even among Unix systems, code that used volatile would not be
	portable!  Then maybe IEEE would have to get into the act and
	define a superset of ANSI C (called POSIX C?) which specifies
	a standard syntax for the volatile #pragma.  Ugg!
FLAME OFF

Volatile must stay, noalias must go!

Pablo Halpern		|	mit-eddie \
Polygen Corp.		|	princeton  \ !polygen!pablo  (UUCP)
200 Fifth Ave.		|	bu-cs      /
Waltham, MA 02254	|	stellar   /