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