Re: rand() is broken
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 a test. 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. Regards, Edward. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
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 host OS changes. 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, No, that wasn't what I meant; yes, there are things should be able to rely on not changing between platforms, however ... The point of compatibility is to not break interfaces unless there is a significant benefit. ... I think there is more than one level of 'compatibility'; I for one would not expect random() to return the same results across platforms, certainly, or even between seperate releases of one platform, even though its API may be the same. For two reasons, mainly, the first that you know someone will change it somewhere anyway ;-), and second I think that's placing too much of 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()? If you require x implementation of random(), then I don't think that it's so bad that you should be expected to provide it yourself, rather than assuming this is what the OS uses. But then maybe this comes down to difference of opinion. Would you have a problem with changes in the TCP/IP stack changing the content of packets sent out when you connect(), if it breaks your TCP/IP simulations? Regards, Edward. (PS: Even though it's rand(), not random() being changed, I think this issue applies to both..) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
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() 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()/random() -- either way, the same thing applies, it just happens you use random() rather than rand(). (I see no problem to changing either; do you object to this rand() change on the same basis?) Regards, Edward. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
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 have a portable RNG if your host OS changes. 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 c) if they really need their own specific RNG, they include it themselves, and don't rely on libc at all. So I fail to see the problem here. Regards, Edward. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
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 predictability of the system. Changing a critical function like rand() when we know that there are applications which depend on its output I would say that depending on the internal algorithm used by rand() (or random()) is a bad idea; however, I don't know what the relevant standards say about this, so I won't say any further. (Why is it a bad idea? Because I'm not going to write software which makes this assumption; I'm sure that even if at some point in time all systems use an identical algorithm, at some point my software will have to run on a system which uses something different. So if I really need it, I will take rand() from libc and place it in my own code.) does not seem like a good idea. A seperate function for those who need cryptographic randomness seems like a _much_ better idea. I'm not sure Yet Another RNG API (of course arc4random() already exists) gains anything unless rand()/random() absolutely cannot be changed; and as I say I'm not convinced this is the case. Doesn't even the 0 / RAND_MAX fix change the algorithm? Software which relies on that behaviour will break .. This is my person opinion. I am not a developer so please take my comments as such. Likewise. Regards, Edward. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
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 out what you mean by this. Are you saying that it's assumed random()'s API won't changed because it's guaranteed by BSD? Regards, Edward. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
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 than the developer (as I'd assumed), then I see what you mean (you can do ld hacks and so on, but ..) I'm not sure Yet Another RNG API (of course arc4random() already exists) gains anything unless rand()/random() absolutely cannot be changed; and as I say I'm not convinced this is the case. I am by no means convinced either. I do, however, think this is something that should not be changed without a lot of consideration and testing. IMHO, it shouldn't break things (ie, things shouldn't be relying on it); but, well, I can accept there might be something that does. I do find it hard to believe though; this 'simulation' problem is the first I've heard of it, and it doesn't look like an insurmountable one. Your point about arc4random() is a good one. Why depend on rand() for cryptographic randomness when we already have arc4random()? Because arc4random() is not portable. I would rather rely on the OS having a useful rand() RNG rather than #ifdef'ing on this that and the other to choose the correct one. Doesn't even the 0 / RAND_MAX fix change the algorithm? Software which relies on that behaviour will break .. [...] I don't recall advocating that change either. Well, no -- but are you against it? Where is the line drawn? Regards, Edward. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
