Eric Blake <ebl...@redhat.com> writes: > 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.
Ah thanks for checking with what POSIX actually says. Yes, I agree we should try to make gnulib's stdlib.h set RAND_MAX if it is not available from the system's stdlib.h. Looking further, it seems struct random_data and the other functions are glibc inventions, and they are specified in glibc's stdlib.h. So arguable they should be part of gnulib's stdlib replacement? Or should we require a 'stdlib-gnu' for that? There is no doc/glibc-headers/stdlib.texi or any discussion in doc/posix-headers/stdlib.texi about this, which is a situation that could probably be improved. >> (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? I don't recall at this point (this was done in 2008) so probably I can live with whatever change we do here. My concern was more on a generic level. /Simon
