Path: utzoo!attcan!uunet!husc6!mailrus!ames!ll-xn!mit-eddie!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: volatile: a summary
Message-ID: <1174@mcgill-vision.UUCP>
Date: 20 Jun 88 08:56:30 GMT
References: <11837@mimsy.UUCP> <796@l.cc.purdue.edu>
Organization: McGill University, Montreal
Lines: 29

In article <796@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes:
> [pseudo-random numbers]  At each stage, one wishes to get the _next_
> number.  There are many ways to do this; the simplest, and one of the
> slowest, is to do something like

> 	x = random();

> each time one is needed.  Now it is essential that the computation of
> random() be done at _each_ call.  Volatile beats all of the kludges I
> have seen to accomplish this.

Volatile is not necessary to ensure this.  The compiler is required to
behave as if the calls were made as written; since random() has side
effects, this involves performing those side effects.  This means
either actually performing the calls or somehow moving the computation
that goes on in random() into the caller - effectively inlining the
call.  Either way is fine: you get a new "random" number each time
flow-of-control passes that point, which is what you wanted.

The compiler is not permitted to use CSE as an excuse to throw away
routine calls (in the absence of hard information that it's safe to do
so, for example, a declaration that the routine is a pure function, or
source code to it being available at the time).  Imagine what could
happen if this were done to read(), for example....

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu