Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: Hey buddy, pick on a keyword your own size!
Message-ID: <493@cresswell.quintus.UUCP>
Date: 23 Dec 87 23:50:44 GMT
References: <10972@brl-adm.ARPA>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 49
Summary: volatile =/= mapped I/O

In article <10972@brl-adm.ARPA>, TLIMONCE%DREW.BITNET@CUNYVM.CUNY.EDU writes:
> Someone asked, "Why not use violate?"  Good question.  Violate implies
> that it is a IO location (i.e. memory mapped).  If you have a pointer
> to a violate int, that may be pointed to a constant memory location who's
> value is (ummm... think of a good example... ummm) the status of a serial
> port.  noalias implies that the location will change due to pointers.
Presumably he means 'volatile'.

'volatile' does NOT mean "IO location".  It means "hey Mr compiler, this
may change when you're not expecting it, so each reference had better
use the original rather than a copy".  One reason for wanting it in all
C compilers, not just ones on micros, is that a volatile location may be
changed by a signal handler.  E.g.

	volatile int ticks;
	int ordinary;

	my_alarm_handler()
	    {
		ticks++;
		CHECK( alarm(1) );
	    }

	main()
	    {
		int i;

		ticks = 0;
		CHECK( signal(SIGALRM, my_alarm_handler) );
		CHECK( alarm(1) );
		i = ticks;
		ordinary = 1;
		printf("ticks = %d, ordinary = %d\n", ticks, ordinary);
	    }

The point is that a C compiler *may* treat the printf() call as
		printf(..., ticks, 1);
mut *may not* treat the printf() call as
		printf(..., i, ordinary);
nor as
		printf(..., 0, ordinary);
even though i hasn't changed, so is still "obviously" equal to ticks.
This is clearly the right way around:  most variables aren't going to
change unexpectedly, and it is the abnormal ones which are flagged.

It is fairly easy to determine the set of variables which need to be
declared volatile:  every variable changed by a signal handler and
every variable visible to another process (whether mapped I/O, mapped
virtual memory, or whatever).