On 08/29/2013 09:43 AM, Eric Blake wrote: > On 08/29/2013 09:35 AM, Jason Helfman wrote: > >>>> >>> stdlib.h:#define RAND_MAX 0x7fffffff > > Good. > >>> >>> -jgh >>> >> >> And on our current head release (10) it is this: >> >> #define RAND_MAX 0x7ffffffd > > Huh? Why is this not 2**n-1? That violates assumptions we have made, > and is WHY your compile failed. It has nothing to do with clang vs. gcc > (both compilers would fail), it has to do with your changed system > header resulting in violating assumptions that hold in ALL OTHER > IMPLEMENTATIONS, that random numbers are evenly distributed within a > range of a power of 2. > http://lists.freebsd.org/pipermail/svn-src-head/2013-July/049076.html makes it look like the reduction in range was _intentional_? Yuck. A non-power-of-2 random generator adds needless complexity to the user. 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. I also intend to open a bug against POSIX to request that RAND_MAX be required to be 2**n-1, rather than relying on the assumption that everyone so far, until FreeBSD 10, has happened to meet that requirement. -- 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