Date: Tue, 17 Nov 1998 15:52:49 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Kbwms AT aol DOT com cc: djgpp-workers AT delorie DOT com Subject: Re: src/libc/ansi/stdlib/rand.c In-Reply-To: <173b7616.365163e8@aol.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com On Tue, 17 Nov 1998 Kbwms AT aol DOT com wrote: > Further, the fact that the generator is cyclic means that the numbers > ``stolen'' at the beginning of the sequence must eventually reappear. I guess I didn't make myself clear enough. Here's the problem I had in mind. Some programs depend on the exact sequence of random values being generated, and their order. For example, consider a Monte-Carlo simulation that computes a 2-dimensional integral by taking random (x,y) pairs and doing some computations with them. In this setup, when you debug or otherwise investigate the program, you need the entire sequence to repeat itself, in the same order, each time you rerun the program. Otherwise, you cannot compare results of two runs. Now, consider the extreme (and absurd) case where the underlying libc.a installs a handler for a timer tick, and that handler calls `rand' for some reason. In this case, there's no way you could ever have two comparable runs, because the library changes the random sequence from under your feet! It doesn't help that the ``stolen'' number will later (in about a millenium ;-) reappear, because I need those numbers in pairs. (Note that I didn't just invent the above (except that the example with the timer tick is intentionally absurd); I actually had such cases on my hands, but the villain of course was some user-level function which would interfere in an unpredictable manner.) I guess the people who put that requirement into the Standard wanted to make sure such problems never happen due to the library implementation. To me, this makes a perfect sense.