On 02/19/2011 08:38 AM, Simon Josefsson wrote: > Paul Eggert <egg...@cs.ucla.edu> writes: > >> +2011-02-08 stdlib Unless the random_r module is also used, this >> + module no longer guarantees that the following >> are >> + defined: struct random_data, RAND_MAX, random_r, >> + srandom_r, initstate_r, setstate_r. >> + > > This feels a bit surprising -- usually including a gnulib header module > should make it POSIX compliant, but if stdlib.h is missing RAND_MAX it > wouldn't be a POSIX compliant header replacer. Have I missed > discussions of changing the gnulib policy here?
Of all of these, RAND_MAX is the only value required by POSIX; it is also the value that is easiest to provide without also defining all the other structs and interfaces. Maybe we should tweak things to provide RAND_MAX always. > > (The reason I added struct random_data detection to stdlib.h was IIRC > that I only needed the struct and not the functions, so pulling in the > entire functions would be wasteful for me.) However, that won't help with your desire to get struct random_data; maybe that means we need an intermediate module for the struct, where you could use that module and where random_r could depend on that intermediate module. Conversely, what use do you have for struct random_data that does not involve random_r? Nothing else in the standard requires it, and if you aren't using random_r, why can't you maintain your own struct for pseudo-random generator state? -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
