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 random_r(). 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
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list