Re: * NEWS: Mention 2011-02-08 change to stdlib.

[Simon Josefsson]

Eric Blake <address@hidden> writes:

> On 02/19/2011 08:38 AM, Simon Josefsson wrote:
>> Paul Eggert <address@hidden> 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