> > another suggestion: why not fold your algorithm change in > > that function? For example, > > > > initstate(seed, "RC4", 3); > > > > changes the algorithm to RC4. Yes, this is a change in the > > interface but one I am sure most people can live with. > > No. Evil interface change. #ifdef hell while programs try to > figure out OS differences.
How so? This or a similar change is upward compatible in that the existing behavior is left unchanged and it gives you a way to replace the algorithm. The basic issue is just what is the expected and (implicitly) promised behavior of random(). AFAIK all random(3) implementations in various versions of Unix come from Earl's original 4.2BSD implementation so in my view the _expected_ behavior is to see the _exact_ same sequence starting from a given seed. This function is called "random()" but it is equivalent to a mathematical function which must provide the same sequence for the exact same input. You and a number of other people are saying that the exact sequence is *not* promised so you are free to change the algortithm as long as the statistical distribution is uniform. Earl chose to name his new implementation random() [even though clearly he was replacing rand(3)] probably to not break any existing scripts. In my view any further behavior change should either use a new name or make an upward compatible change. Now the question is whether perl uses system provided random() or rand() or its own since perl is used extensively in ASIC verification. Any way, this is my last email on this subject since neither one of us is convincing the other. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message