On 08/29/2013 09:43 AM, Eric Blake wrote:
On 08/29/2013 09:35 AM, Jason Helfman wrote:
stdlib.h:#defineRAND_MAX0x7fff
Good.
-jgh
And on our current head release (10) it is this:
#define RAND_MAX0x7ffd
Huh? Why is this not 2**n-1? That violates
On Thu, Aug 29, 2013 at 09:52:52AM -0600, Eric Blake wrote:
On 08/29/2013 09:43 AM, Eric Blake wrote:
On 08/29/2013 09:35 AM, Jason Helfman wrote:
stdlib.h:#defineRAND_MAX0x7fff
Good.
-jgh
And on our current head release (10) it is this:
#define
On 08/29/2013 09:52 AM, Eric Blake wrote:
#define RAND_MAX0x7ffd
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
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
On 08/29/2013 10:33 AM, Eric Blake wrote:
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
