Date: Thu, 29 Aug 2013 10:33:20 -0600 From: Eric Blake <eblake@redhat.com> To: "Daniel P. Berrange" <berrange@redhat.com> Cc: svn-src-head@freebsd.org, libvir-list <libvir-list@redhat.com>, Jason Helfman <jgh@freebsd.org> Subject: Re: [libvirt] FreeBSD, no gcc present libvirt build issue Message-ID: <521F77D0.4010904@redhat.com> In-Reply-To: <20130829160349.GV14547@redhat.com> References: <CAMuy=%2BiG20hs9b%2BD210=TZ50weyaJoPK8NZ8Mgea8s1A2UDQhw@mail.gmail.com> <521F63F4.4020406@redhat.com> <CAMuy=%2BhO15c_0EdjnMQMtL5OGESfQkkvjZ5oUwRGv2%2B0VB6U0w@mail.gmail.com> <CAMuy=%2BhgHARZyAUgiVaf0hdOSpTQOGRubucCY%2BQ6-kzDN8a5Ng@mail.gmail.com> <521F6C0F.9060007@redhat.com> <521F6E54.1070104@redhat.com> <20130829160349.GV14547@redhat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ni3INlrofdMhmrmoTwFt9g3Utxtb7w4LQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 even= ly >> distributed, I will have to tweak libvirt's call to truncate every cal= l >> 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 bit= s >> returned, and only using 28 instead of 31 bits of randomness per call)= =2E >> But I would MUCH rather prefer that FreeBSD revisit their decision, a= nd >> guarantee that random output be evenly distributed across the full 31 >> bits to begin with. >=20 > 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --ni3INlrofdMhmrmoTwFt9g3Utxtb7w4LQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJSH3fQAAoJEKeha0olJ0Nq8X8IAIcSWDLm4y7ogEUjrx6mTr/f 0rRUs50m58BQYtH0OXqelBDs5ShphhM60+8LpJ5kn9UICu++9/EPzETAyGytaYcy 6is3LKfBaY4w7RYqCsLowqe5zy+Dni1DyAZ9JWd0ZMIaj+mty9PDEpoii91l8Cru uInNbGz1YEwV5T0xURroLSMfjGIEPMAjFTvYxWnmQLLwXRBJcjc2yq2t9b4xvaub CubnXItenau2acXD7ajRvSO3RpWa46C07+MWu96amTqSxG9JGSHDnpWFKLeWtB5p yKZq4rUcTT+sjNhvIyrT+YgJDauFnS3RJ/er4M8yzkfM5NX4pUfQGjvUksKMatk= =EfEB -----END PGP SIGNATURE----- --ni3INlrofdMhmrmoTwFt9g3Utxtb7w4LQ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?521F77D0.4010904>