[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] FreeBSD, no gcc present libvirt build issue

On 08/29/2013 10:03 AM, Daniel P. Berrange wrote:

>> I think I can fix libvirt to work around the boneheaded decision;
>> basically, since we cannot trust the full range of random_r to be evenly
>> distributed, I will have to tweak libvirt's call to truncate every call
>> to random_r to a subset of bits that are more likely to be evenly
>> distributed (maybe by shifting off the most- and least-significant bits
>> returned, and only using 28 instead of 31 bits of randomness per call).
>>  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.
> Since gnulib has a working random_r() function can we just make
> gnulib replace the boneheaded freebsd impl ?

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.

I guess that means we should't be worrying about RAND_MAX in the first
place, as it is tied to the (potentially algorithmically weaker) rand(),
and need not have any bearing on the fact that we already use gnulib's

I'll play around with a patch.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]