Bakul Shah writes:
> > 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.

It requies that programmers know about evil localisms. It screws over
portability of source code.

> The basic issue is just what is the expected and (implicitly)
> promised behavior of random().

You believe one implied output. Another programmer believes another.
Only way out is to make the routine "honest".

> 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.

Maybe that is the greatgrandfather. The grandchildren speak with
different accents now. :-)

> 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.

Not quite. Close. You compile program on a machine with a
constant argument to srand[om](). Run the more than once,
and rand[om]() will give you the same sequence.

Another OS, another time, another version of libc, the sequence
will again be constant, but different from last time.

> 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.

You have said that before, and I understand your words.

I disagree with them.

> Now the question is whether perl uses system provided
> random() or rand() or its own since perl is used extensively
> in ASIC verification.

Different question. Ask the perl developers.

Mark Murray
iumop ap!sdn w,I idlaH

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to