FreeBSD's rand() implementation has been broken for the past 23
months, since the following commit:
Revision 1.3 / (download) - annotate - [select for diffs], Tue Feb 27 14:42:19 2001
UTC (23 months ago) by ache
Branch: MAIN
Changes since 1.2: +26 -0 lines
Diff to previous 1.2 (colored)
Use
On Sat, Feb 01, 2003 at 23:06:50 -0800, Kris Kennaway wrote:
> FreeBSD's rand() implementation has been broken for the past 23
> months, since the following commit:
> i.e. the first value returned from rand() is correlated with the seed
> given to srand(). This is a big problem unless your seed i
On Sun, Feb 02, 2003 at 12:04:22PM +0300, Andrey A. Chernov wrote:
> Yes, first value correlation is there, but old formulae have even worse
> effect "The random sequences do not vary much with the seed", as source
> file comments and whole discussion about old RNG bad effects shown. I.e.
> for
On Sun, Feb 02, 2003 at 01:11:06 -0800, Kris Kennaway wrote:
>
> Another problem (noticed by tjr) is that once the sequence hits '0' it
> jumps to INT_MAX and stays there forever. For example, seeding with
> srand(0) produces nothing but INT_MAX from rand().
>
> It looks like a lot more validati
In message <[EMAIL PROTECTED]>, "Andrey A. Chernov" writes:
>
>--SUOF0GtieIMvvwua
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>Content-Transfer-Encoding: quoted-printable
>
>On Sun, Feb 02, 2003 at 01:11:06 -0800, Kris Kennaway wrote:
>>=20
>> Another problem (noticed b
[EMAIL PROTECTED] writes:
> >BTW, note that new formulae also used in the kernel (by BSD developers)
> >and taken from there - libkern/random.c - so all you say is true there
> >too.
>
> It should be nuked from the kernel, and arc4random() used instead.
I agree. If no-one objects, I'll do this?
On Sun, Feb 02, 2003 at 01:11:06 -0800, Kris Kennaway wrote:
>
> Another problem (noticed by tjr) is that once the sequence hits '0' it
> jumps to INT_MAX and stays there forever. For example, seeding with
> srand(0) produces nothing but INT_MAX from rand().
>
> It looks like a lot more validati
Thus spake Andrey A. Chernov <[EMAIL PROTECTED]>:
> Yes, first value correlation is there, but old formulae have even worse
> effect "The random sequences do not vary much with the seed", as source
> file comments and whole discussion about old RNG bad effects shown. I.e.
> for different time+PID
On Sun, Feb 02, 2003 at 03:48:17 -0800, David Schultz wrote:
> Specifically, rand() isn't very interesting in the lower-order
> bits, and it spectacularly fails nearly all of Marsaglia's
It seems that you speak about old formulae, we use new one (which
intended to fix low-ordered bits), see our
On Sun, Feb 02, 2003 at 13:26:21 +0300, Andrey A. Chernov wrote:
> Workaround I find so far is something like that
>
> #define MASK 123459876
I found nothing better. Here is fix for 0 problem I plan to commit:
--- stdlib/rand.c.old Sat Jan 4 20:39:19 2003
+++ stdlib/rand.c Sun Feb 2 1
On Sun, 2 Feb 2003, Andrey A. Chernov wrote:
> On Sun, Feb 02, 2003 at 13:26:21 +0300, Andrey A. Chernov wrote:
>
> > Workaround I find so far is something like that
> >
> > #define MASK 123459876
>
> I found nothing better. Here is fix for 0 problem I plan to commit:
I think it's worthwhile to w
On Sun, Feb 02, 2003 at 04:38:53 -0800, Doug Barton wrote:
>
> I think it's worthwhile to wait till we get a chance to try arc4random().
This is libc's rand/random, it can't be fixed with arc4random() as
designed.
> Also, have you run the code you're proposing through the tests in the post
> th
On Sun, Feb 02, 2003 at 03:30:35PM +0300, Andrey A. Chernov wrote:
> On Sun, Feb 02, 2003 at 13:26:21 +0300, Andrey A. Chernov wrote:
>
> > Workaround I find so far is something like that
> >
> > #define MASK 123459876
>
> I found nothing better. Here is fix for 0 problem I plan to commit:
>
>
On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote:
>
> I believe that this change just moves the "bad" seed to 123459876; after
> calling srand() with that seed, each call to rand() returns 0.
Yes. Nothing better is possible for this formulae and this is documented
in algorithm, some valu
On Sun, Feb 02, 2003 at 16:42:25 +0300, Andrey A. Chernov wrote:
> On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote:
> >
> > I believe that this change just moves the "bad" seed to 123459876; after
> > calling srand() with that seed, each call to rand() returns 0.
>
> Yes. Nothing better
On Sun, Feb 02, 2003 at 17:02:23 +0300, Andrey A. Chernov wrote:
>
> I'll produce and send it a bit later.
Here it is.
--- stdlib/rand.c.old Sat Jan 4 20:39:19 2003
+++ stdlib/rand.c Sun Feb 2 17:06:08 2003
@@ -72,10 +72,13 @@
*/
long hi, lo, x;
+ /* Can't be initiali
David Schultz <[EMAIL PROTECTED]> writes:
> [2] http://stat.fsu.edu/~geo/diehard.html (you need ports/lang/f2c)
There's a native C version on Marsaglia's random number CD:
http://stat.fsu.edu/pub/diehard/cdrom/die.c/
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [
"Jeroen C. van Gelderen" writes:
> Wouldn't it be a good idea to change the name at the same time? Or
> should it be retained for compatibility reasons with other BSDs?
>
> Currently the name needlessly exposes implementation detail. Callers
> expect good, cheap, non-blocking randomness but don'
On Sun, Feb 02, 2003 at 15:32:32 +, Mark Murray wrote:
> "Jeroen C. van Gelderen" writes:
> > Wouldn't it be a good idea to change the name at the same time? Or
> > should it be retained for compatibility reasons with other BSDs?
> >
> > Currently the name needlessly exposes implementation de
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 04:38:53 -0800, Doug Barton wrote:
> >
> > I think it's worthwhile to wait till we get a chance to try arc4random().
>
> This is libc's rand/random, it can't be fixed with arc4random() as
> designed.
Why not? Arc4 is a) deterministic and b)
"Andrey A. Chernov" writes:
> On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote:
> >
> > I believe that this change just moves the "bad" seed to 123459876; after
> > calling srand() with that seed, each call to rand() returns 0.
>
> Yes. Nothing better is possible for this formulae and th
"Andrey A. Chernov" writes:
> > Objections?
>
> We can't, simple because sequence must be repeated for the same seed
> across the calls.
RC4 is repeatable.
M
--
Mark Murray
iumop ap!sdn w,I idlaH
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of t
On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
>
> Why not? Arc4 is a) deterministic and b) good for all bits.
If you mean arc4random() function - not, because it use true randomness,
if you mean RC4 algorithm, probably yes, but we should compare its
distribution with our current vari
On Sun, Feb 02, 2003 at 17:34:19 +, Mark Murray wrote:
> "Andrey A. Chernov" writes:
> > > Objections?
> >
> > We can't, simple because sequence must be repeated for the same seed
> > across the calls.
>
> RC4 is repeatable.
It seems we mean different things saying arc4random(), see my answ
On Sun, Feb 02, 2003 at 21:20:09 +0300, Andrey A. Chernov wrote:
> On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
> >
> > Why not? Arc4 is a) deterministic and b) good for all bits.
>
> If you mean arc4random() function - not, because it use true randomness,
> if you mean RC4 algorith
In message <[EMAIL PROTECTED]>, "Andrey A. Chernov" writes:
>On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
>>
>> Why not? Arc4 is a) deterministic and b) good for all bits.
>
>If you mean arc4random() function - not, because it use true randomness,
>if you mean RC4 algorithm, probably
On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote:
>
> Anyway, last time we discussed this, I think we stuck with the rand()
> we had because we feared that people were using it's repeatable well
> documented sequence of random numbers in regression testing.
As documented, it must b
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote:
> >
> > Why not? Arc4 is a) deterministic and b) good for all bits.
>
> If you mean arc4random() function - not, because it use true randomness,
> if you mean RC4 algorithm, probably yes, but we should compar
In message <[EMAIL PROTECTED]>, "Andrey A. Chernov" writes:
>On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote:
>>
>> Anyway, last time we discussed this, I think we stuck with the rand()
>> we had because we feared that people were using it's repeatable well
>> documented sequence o
In message <[EMAIL PROTECTED]>, Mark Murray wr
ites:
>We have most of this, and RC4 can deliver. RC4's "licence" is
>fine. Call it "ArCFour" and there is no problem. The code is
>small, fast and repeatable, and meets conditions 1-4 above.
There are some concerns about RC4's strength and predictab
> Good point. We can re-implement random() internally with arc4rand().
>
> Objections?
Guys, please realize that random() is also used in generating
simulation inputs (or timing or whatever). If you go change
the underlying algorithm or its parameters one can't generate
the same sequence from th
On Sun, Feb 02, 2003 at 19:43:44 +0100, [EMAIL PROTECTED] wrote:
>
> Please surf the mail-archives to find the discussion, it contained
> a lot of good arguments from both sides, arguments which should
> be thought about before changing rand().
I remember well that we decide to allow it be change
On Sun, Feb 02, 2003 at 18:36:02 +, Mark Murray wrote:
> I think we need four things.
>
> 1) void srandom(int arg) which uses the argument to seed.
> 2) void srandomdev(void) which uses system entropy to seed.
> 3) int random(void) which returns a number statistically
>random in all bits.
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote:
>
> > Anyway, last time we discussed this, I think we stuck with the
> > rand() we had because we feared that people were using it's
> > repeatable well documented sequence of random numbers in regression
[EMAIL PROTECTED] writes:
> RC4 can be implemented in about 4 lines of C.
Yah. If you like writing obfuscated C!
> Anyway, last time we discussed this, I think we stuck with the rand()
> we had because we feared that people were using it's repeatable well
> documented sequence of random numbers i
On Sun, Feb 02, 2003 at 19:47:12 +0100, [EMAIL PROTECTED] wrote:
> In message <[EMAIL PROTECTED]>, Mark Murray wr
> ites:
>
> >We have most of this, and RC4 can deliver. RC4's "licence" is
> >fine. Call it "ArCFour" and there is no problem. The code is
> >small, fast and repeatable, and meets cond
[EMAIL PROTECTED] writes:
> In message <[EMAIL PROTECTED]>, Mark Murray
> wr
> ites:
>
> >We have most of this, and RC4 can deliver. RC4's "licence" is
> >fine. Call it "ArCFour" and there is no problem. The code is
> >small, fast and repeatable, and meets conditions 1-4 above.
>
> There are som
> As I said, I don't know how big a concern this is. But last time
> it was enough of a concern to make us keep rand() as it was.
[I know you are talking about rand() but Mark Murray's
earlier email about wanting to re-implement random() really
concerned me so I want to make sure my point gets ac
Bakul Shah writes:
> > Good point. We can re-implement random() internally with arc4rand().
> >
> > Objections?
>
> Guys, please realize that random() is also used in generating
> simulation inputs (or timing or whatever). If you go change
> the underlying algorithm or its parameters one can't g
Bakul Shah writes:
> Not changing random() was of real concern to me when I was
> doing chip simulations. ASIC design verification folks won't
> be happy if the rug is pulled out from under them. In
> general crypto and simulation needs are different and I don't
> trust the crypto guys to look ou
On Sun, Feb 02, 2003 at 07:08:47PM +, Mark Murray wrote:
> RC4 is _utterly_ repeatable, given a particular seed/key.
I presume it also produces reasonably uniform output for most
seeds too.
> > The old 16 bit rand() was broken enough that it didn't matter
> > much (read: _I_ don't care) if it
On Sunday 02 February 2003 6:48 pm, Bakul Shah wrote:
> Guys, please realize that random() is also used in generating
> simulation inputs (or timing or whatever). If you go change
> the underlying algorithm or its parameters one can't generate
> the same sequence from the same seed when repeating
David Malone writes:
> On Sun, Feb 02, 2003 at 07:08:47PM +, Mark Murray wrote:
> > RC4 is _utterly_ repeatable, given a particular seed/key.
>
> I presume it also produces reasonably uniform output for most
> seeds too.
Yes. Modulo the requirement to "burn" a bit of output after a
reseed.
>
> RC4 is _utterly_ repeatable, given a particular seed/key.
May be but it is not the same as the current random(). Also,
I know you will want to change it the next time some one
points out a problem with RC4.
> Yes. And it breaks, and we have a complainant.
So create a new function! Or use a d
> > I presume it also produces reasonably uniform output for most
> > seeds too.
> Yes. Modulo the requirement to "burn" a bit of output after a
> reseed.
I guess the crypto guys would have junked it otherwise ;-)
> > I thought the complaint was about rand, not random?
> Erm, yes. Similar diffe
> Maybe I missed something, but why cannot you just rip random() from libc,
> rename it to bakul_shah_random() and use that in your testing code? Then you
> are safe from any changes to random(), and indeed have a portable RNG if your
> host OS changes.
Yes, *I* can do it but I don't work at eve
On Sunday 02 February 2003 8:06 pm, Bakul Shah wrote:
> > Maybe I missed something, but why cannot you just rip random() from libc,
> > rename it to bakul_shah_random() and use that in your testing code? Then
> > you are safe from any changes to random(), and indeed have a portable RNG
> > if your
Bakul Shah writes:
> > RC4 is _utterly_ repeatable, given a particular seed/key.
>
> May be but it is not the same as the current random(). Also,
> I know you will want to change it the next time some one
> points out a problem with RC4.
Yes. This is called "fixing bugs". We (OS maintainers) res
Bakul Shah writes:
> Yes, *I* can do it but I don't work at every place they do
> simulation! If in the extreme you are suggesting that a
> portable application shouldn't rely on any OS features, you
> are of course right but that kind of makes mockery of any
> claims of compatibility. The point
On Sun, Feb 02, 2003 at 20:05:29 +, David Malone wrote:
> > > I presume it also produces reasonably uniform output for most
> > > seeds too.
>
> > Yes. Modulo the requirement to "burn" a bit of output after a
> > reseed.
>
> I guess the crypto guys would have junked it otherwise ;-)
Notice t
> a restriction on the OS. If FreeBSD makes random2() using RC4 to avoid
> changing rand() or random(), will people then start relying on random2()'s
> behaviour, and when someone finds a problem in RC4, then the next will be
> random3()?
What I am suggesting is to leave random() as it is and
On Sun, Feb 02, 2003 at 12:39:50 -0800, Bakul Shah wrote:
>
> Note that it is rand() that is broken, not random() as can be
> seen by modifying Kris Kennaways' test so I don't see why
> Mark Murray was talking about changing it in the first place.
About correlation bug: it is srand() which is bro
On Sun, Feb 02, 2003 at 12:06:56PM -0800, Bakul Shah wrote:
> > Maybe I missed something, but why cannot you just rip random() from libc,
> > rename it to bakul_shah_random() and use that in your testing code? Then you
> > are safe from any changes to random(), and indeed have a portable RNG if y
On Sun, Feb 02, 2003 at 11:55:25AM -0800, Bakul Shah wrote:
> > RC4 is _utterly_ repeatable, given a particular seed/key.
>
> May be but it is not the same as the current random(). Also,
> I know you will want to change it the next time some one
> points out a problem with RC4.
Since you keep ta
> Would you prefer that we defined random() as
>
> int
> random(void)
> {
> static int retval = 0;
>
> return retval++;
> }
No because that would be a change from the exisiting random()
behavior :-)
As I indicated in my earlier email random() is not broken,
srand() is (as corrected
> Since you keep talking about random(), I must conclude you're
> knee-jerking, since we're not discussing that function. Please stay
> on-topic :-)
Read through the thread. In particular see Mark's message
<[EMAIL PROTECTED]> where he
says
Good point. We can re-implement random() internall
Bakul Shah writes:
> Note that it is rand() that is broken, not random() as can be
> seen by modifying Kris Kennaways' test so I don't see why
> Mark Murray was talking about changing it in the first place.
rand(3) says:
STANDARDS
The rand() and srand() functions conform to ISO/IEC 9899:1990
On Sun, Feb 02, 2003 at 12:57:45PM -0800, Bakul Shah wrote:
> > Since you keep talking about random(), I must conclude you're
> > knee-jerking, since we're not discussing that function. Please stay
> > on-topic :-)
>
> Read through the thread. In particular see Mark's message
> <[EMAIL PROTECTED
Bakul Shah writes:
> random(3) also provides an initstate() call which presumably
> allows you to change the amount of randomnes. So here is
> another suggestion: why not fold your algorithm change in
> that function? For example,
>
> initstate(seed, "RC4", 3);
>
> changes the algorithm to
On Sunday 02 February 2003 8:39 pm, Bakul Shah wrote:
> What I am suggesting is to leave random() as it is and
> guarantee its behavior won't change and add cryto_random() or
> whatever, and indicate it *may* change.
Where was it indicated that random() wouldn't change?
> Note that it is rand() t
On Sun, 2 Feb 2003, Bakul Shah wrote:
> Yes, *I* can do it but I don't work at every place they do
> simulation!
Well the code is still going to be available in cvs. It's not like we're
going to magically make it disappear. :)
> If in the extreme you are suggesting that a
> portable application
Bakul Shah writes:
> > Since you keep talking about random(), I must conclude you're
> > knee-jerking, since we're not discussing that function. Please stay
> > on-topic :-)
>
> Read through the thread. In particular see Mark's message
> <[EMAIL PROTECTED]> where he
> says
>
> Good point. W
> > 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. #ifd
On Sun, Feb 02, 2003 at 21:23:43 +, Mark Murray wrote:
>
> That was random(9). KERNEL random().
KERNEL random() can be easily implemented (better - replaced) with
arc4random(), there is no objections. But...
1) Implementing random(3) with RC4 is not needed, its algorithm is
already equal or
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 progra
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 21:23:43 +, Mark Murray wrote:
> >
> > That was random(9). KERNEL random().
>
> KERNEL random() can be easily implemented (better - replaced) with
> arc4random(), there is no objections. But...
>
> 1) Implementing random(3) with RC4 is no
On Sun, Feb 02, 2003 at 22:19:33 +, Mark Murray wrote:
> > 1) Implementing random(3) with RC4 is not needed, its algorithm is
> > already equal or better.
>
> Rubbish. :-) RC4's internal state is 256 bytes. In theory, its
> cycle-of-repetition is 2^(8*256) bits.
This is comparable with rand
On Sun, Feb 02, 2003 at 01:59:25PM -0800, Bakul Shah wrote:
>
> 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
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 22:19:33 +, Mark Murray wrote:
>
> > > 1) Implementing random(3) with RC4 is not needed, its algorithm is
> > > already equal or better.
> >
> > Rubbish. :-) RC4's internal state is 256 bytes. In theory, its
> > cycle-of-repetition is 2^(
On Sun, Feb 02, 2003 at 22:35:54 +, Mark Murray wrote:
>
> I stand (somewhat) corrected. The random() code is _nasty_ complexity-wise.
> Its not obvious how it works.
>
> RC4 is 10-20 lines and clean with no magic numbers.
That's why randomness tests + mathematician to interpretate their res
Thus spake Bakul Shah <[EMAIL PROTECTED]>:
> > As I said, I don't know how big a concern this is. But last time
> > it was enough of a concern to make us keep rand() as it was.
>
> [I know you are talking about rand() but Mark Murray's
> earlier email about wanting to re-implement random() really
"Andrey A. Chernov" writes:
> On Sun, Feb 02, 2003 at 22:35:54 +, Mark Murray wrote:
> >
> > I stand (somewhat) corrected. The random() code is _nasty_ complexity-wise.
> > Its not obvious how it works.
> >
> > RC4 is 10-20 lines and clean with no magic numbers.
>
> That's why randomness tes
On Sun, Feb 02, 2003 at 02:37:25PM -0800, Steve Kargl wrote:
> FreeBSD Redhat SunOS
> 660787754660787754645318364
FWIW - AIX aggrees with Solaris.
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
> Last 10 digits.
>
> FreeBSD Redhat SunOS
> 660787754660787754645318364
> 3275486913275486911583150371
> 2009993994 2009993994 715222008
> 1653966416 1653966416 1349166998
> 1074113008 1074113008 566227131
> 2142626740 2142626740 1382825076
> 15177758
[From address modified because I don't want every message in this
thread to end up in my personal mailbox. I'll read them in the
list, thank you very much.]
On Sun, Feb 02, 2003 at 09:23:43PM +, Mark Murray wrote:
> Bakul Shah writes:
> > > Since you keep talking about random(), I must conclu
Mark Murray wrote:
> "Jeroen C. van Gelderen" writes:
> > Wouldn't it be a good idea to change the name at the same time? Or
> > should it be retained for compatibility reasons with other BSDs?
> >
> > Currently the name needlessly exposes implementation detail. Callers
> > expect good, cheap, non-
Mark Murray wrote:
> "Andrey A. Chernov" writes:
> > > Objections?
> >
> > We can't, simple because sequence must be repeated for the same seed
> > across the calls.
>
> RC4 is repeatable.
I tried that, and it didn't repeat the sequence I got when I
previously used "rand()"... 8-) 8-).
-- Terry
Edward Brocklesby wrote:
> On Sunday 02 February 2003 6:48 pm, Bakul Shah wrote:
> > Guys, please realize that random() is also used in generating
> > simulation inputs (or timing or whatever). If you go change
> > the underlying algorithm or its parameters one can't generate
> > the same sequence
* De: David Malone <[EMAIL PROTECTED]> [ Data: 2003-02-02 ]
[ Subjecte: Re: rand() is broken ]
> On Sun, Feb 02, 2003 at 02:37:25PM -0800, Steve Kargl wrote:
> > FreeBSD Redhat SunOS
> > 660787754660787754645318364
>
> FWIW - AIX aggrees w
Mark Murray <[EMAIL PROTECTED]> wrote:
>
>3) int random(void) which returns a number statistically
> random in all bits.
>
>We have most of this, and RC4 can deliver. RC4's "licence" is
>fine. Call it "ArCFour" and there is no problem. The code is
>small, fast and repeatable, and meets conditions
On Sunday 02 February 2003 11:59 pm, Terry Lambert wrote:
> Edward Brocklesby wrote:
> > Maybe I missed something, but why cannot you just rip random() from libc,
> > rename it to bakul_shah_random() and use that in your testing code? Then
> > you are safe from any changes to random(), and indeed
On Sun, Feb 02, 2003 at 04:02:27PM -0800, Juli Mallett wrote:
> * De: David Malone <[EMAIL PROTECTED]> [ Data: 2003-02-02 ]
> [ Subjecte: Re: rand() is broken ]
> > On Sun, Feb 02, 2003 at 02:37:25PM -0800, Steve Kargl wrote:
> > > FreeBSD Redhat
Mark Murray wrote:
> Bakul Shah writes:
> > random(3) also provides an initstate() call which presumably
> > allows you to change the amount of randomnes. So here is
> > another suggestion: why not fold your algorithm change in
> > that function? For example,
> >
> > initstate(seed, "RC4", 3)
> Interesting The SunOS output exactly matches random(3)
> behavior from 4.3BSD! In fact random() remained the same for
> 4.3BSD-Reno, -Tahoe, 4.4BSD-Alpha and Net2.
>
> 4.2BSD random() behavior is different from all of the above.
> There was real bug-fix between 4.2BSD and 4.3BSD.
>
> I do
> > Binary packages from third party software vendors.
>
> What about them? They either,
> a) link to a static libc, and use its rand() always; or
> b) link to a shared libc, and use its rand(), as the binary API hasn't
> changed; or
It isn't a question of the API. It's a question of expected funct
Edward Brocklesby wrote:
> On Sunday 02 February 2003 8:39 pm, Bakul Shah wrote:
> > What I am suggesting is to leave random() as it is and
> > guarantee its behavior won't change and add cryto_random() or
> > whatever, and indicate it *may* change.
>
> Where was it indicated that random() wouldn'
Doug Barton wrote:
> I can think of one significant benefit... I had noticed that my perl
> script to pick random windowmaker themes (which uses rand()) seemed to be
> picking the same themes over and over again. Now I know why. :) I had to
> create a "last seen" list to artificially increase the "
Doug Barton <[EMAIL PROTECTED]> wrote:
>
>I can think of one significant benefit... I had noticed that my perl
>script to pick random windowmaker themes (which uses rand()) seemed to be
>picking the same themes over and over again.
That's a bug in perl's compile-time configuration. It can be told
On Monday 03 February 2003 12:18 am, Don wrote:
> It isn't a question of the API. It's a question of expected function
> output.
Then it's applicable not only to binary packages as Terry states, but any
source that uses rand().
> I run FreeBSD and not Linux because of the stability and predict
Thus spake Andrey A. Chernov <[EMAIL PROTECTED]>:
> On Sat, Feb 01, 2003 at 23:06:50 -0800, Kris Kennaway wrote:
> > FreeBSD's rand() implementation has been broken for the past 23
> > months, since the following commit:
>
> > i.e. the first value returned from rand() is correlated with the seed
>
Steve Kargl wrote:
> I was going to stay out of this, but
>
> #include
> #include
> int main(void) {
> int i;
> long x;
> x = 100L;
> srandom(x);
> for (i = 0; i < 1010; i++) {
> x = random();
> printf("%ld\n", x);
> }
> return 0;
> }
>
> Last 10 digits.
>
> FreeBSD
> > It isn't a question of the API. It's a question of expected function
> > output.
>
> Then it's applicable not only to binary packages as Terry states, but any
> source that uses rand().
I think Terry mentioned binary packages simply because it is harder to fix
them than something available as s
On Monday 03 February 2003 12:20 am, Terry Lambert wrote:
> Edward Brocklesby wrote:
> > Where was it indicated that random() wouldn't change?
>
> Right there in the boot message, and again when you logged in,
> where the system indicated to you that it was a BSD system;
Sorry, I can't quite work
Mark Murray wrote:
> > That's why randomness tests + mathematician to interpretate their results
> > are needed to compare what we have now in random(3) with RC4. Easy and
> > understandable code not always mean better results. We can't switch
> > algorithms blindly, i.e. when their comparative qua
On Sun, Feb 02, 2003 at 04:37:07PM -0800, Terry Lambert wrote:
>
> I can fire up my HP/UX and SunOS 4.1.3-U1 boxes too, if you need
> those, but I'm pretty sure the reason you got a different answer
> for newer Solaris was because it uses the SVR4 code, instead.
>
That's the whole point! You sh
Terry Lambert wrote:
> > Last 10 digits.
> >
> > FreeBSD Redhat SunOS
> 386BSD 0.1+
> patchkitTRU64
Crap.
Ignore these numbers. I replaced the libc implementation on both
these machines, and forgot I had done it. When I put the code
back to what it was, they give the Solar
On Monday 03 February 2003 12:41 am, Don wrote:
> I think Terry mentioned binary packages simply because it is harder to fix
> them than something available as source but I could be mistaken.
Possibly -- if we're looking at this from the point of view of the user of
said binary package, rather th
Don wrote:
> > > It isn't a question of the API. It's a question of expected function
> > > output.
> >
> > Then it's applicable not only to binary packages as Terry states, but any
> > source that uses rand().
>
> I think Terry mentioned binary packages simply because it is harder to fix
> them t
Edward Brocklesby wrote:
> On Monday 03 February 2003 12:20 am, Terry Lambert wrote:
> > Edward Brocklesby wrote:
> > > Where was it indicated that random() wouldn't change?
> >
> > Right there in the boot message, and again when you logged in,
> > where the system indicated to you that it was a BS
Steve Kargl wrote:
> On Sun, Feb 02, 2003 at 04:37:07PM -0800, Terry Lambert wrote:
> > I can fire up my HP/UX and SunOS 4.1.3-U1 boxes too, if you need
> > those, but I'm pretty sure the reason you got a different answer
> > for newer Solaris was because it uses the SVR4 code, instead.
>
> That's
1 - 100 of 152 matches
Mail list logo
