Re: RAND_MAX issue?

On 29.08.2013 22:16, Andrey Chernov wrote:
> On 29.08.2013 21:05, John Baldwin wrote:
>> On Thursday, August 29, 2013 11:59:53 am Jason Helfman wrote:
>>> I am working on trying to resolve a build issue with devel/libvirt, and
>>> posted to the libvirt mailing list, and received this feedback. Please read
>>> this thread, and if you have any thoughts I would be interested in any
>>> resolution.
>>>
>>> Here is a link to the thread:
>>> https://www.redhat.com/archives/libvir-list/2013-August/msg01544.html
>>>
>>> Thanks!
>>
>> It mostly seems to not matter reading the followups.  You would need to
>> ask Bruce what he thinks about the assumption of RAND_MAX being 2^n-1
>> for some n.
>>
> 
> The whole libvirt check looks like Linuxism based on wrong assumption

Moreover, their code have totally wrong assumptions:
https://www.redhat.com/archives/libvir-list/2013-August/msg01556.html
"But I would MUCH rather prefer that FreeBSD revisit their decision, and
guarantee that random output be evenly distributed across the full 31
bits to begin with."

random() output always is full 31 bit and not related to RAND_MAX
anyhow per POSIX. It is only GNU lib which uses RAND_MAX for both rand()
and, incorrectly, for random() too.

They confess it by themselves in this message:
https://www.redhat.com/archives/libvir-list/2013-August/msg01559.html
"Huh - the glibc man pages state that random_r returns RAND_MAX bits.
random_r is a glibc extension: POSIX only requires rand(), rand_r(), and
random(); but even with random(), POSIX has no requirements that it be
related to RAND_MAX - so the fact that glibc equates random()/random_r()
with RAND_MAX is also a glibc extension."

So the correct fix is simple: remove check for RAND_MAX from their
sources along with any RAND_MAX usage, since their code don't even use
rand() but RAND_MAX is only for rand().

-- 
http://ache.vniz.net/
bitcoin:1G6ugdNY6e5jx1GVnAU2ntj2NEfmjKG85r