svn commit: r252608 - in head: include lib/libc/stdlib

[Andrey Chernov]

On 04.07.2013 6:47, Bruce Evans wrote:
> Er, I think it is too dangerous to change either RAND_MAX or the offset
> without more preparation:
> - increasing the range returned (and increasing RAND_MAX to match) would
>   obviously be binary-incompatible.  Old binaries may have the old RAND_MAX
>   built in to them, but will call the new rand().  They would be broken if
>   the new rand() returned a value larger than the old RAND_MAX.  But this
>   change only reduces RAND_MAX.  RAND_MAX was already 1 higher than could
>   be returned.  This change expands the range at the low end, so that 0
>   is now returned, but returning it was always possible and should have
>   occurred.

Currently the range is reduced, not increased. In details:
Old binaries + old libc already have +1 bigger RAND_MAX and never returns 0.
Old binaries + new libc will have +2 bigger RAND_MAX and returns 0 (0 is
allowed by POSIX).
The value bigger than old RAND_MAX will never returned and it even is
impossible with the formula we use and 0 is allowed by POSIX, so I don't
see any binary incompatibilities with that changes.

> - changing the offset is more of a problem.  It changes the sequence
>   generated by each fixed seed.  Of course, the sequence is not guaranteed
>   to be repeated after all system changes.  The C90/C99 specification is
>   actually unusably fuzzy about this.  C99 (n869.txt) says:

...

> Perahps this only says that the sequence shall be repeated within each
> "execution" of a C program, but that is not very useful.  This is not
> fixed in POSIX, at least in old drafts.  POSIX should at least say that
> the sequence shall be repeated across the lifetime of a single process
> (it can be more specific about "execution").  But to be useful, the
> repeatability must be much more than that (certainly across reboots,
> which is already more than POSIX can explicitly specify).

We already pass that moment in the past, changing old&bad formula with
new one which cause the same effect: non-repeating sequence in the very
global scope. We already agree that repeating depends on something like
OS release numbers. I can't find that discussion right now.

> Style bugs:
> - old: initializations in declarations.  The one for 'r' is especially bad.
>   Almost all of the work for the function is done in the initialization.
> - new: initialization not even in declarations.  There is now a statement
>   in the middle of the declarations.  This wouldn't even compile in C90.
>   This is collateral with the old style bugs -- when almost the whole
>   function is written in initializers, it is difficult to insert statements
>   into it without increasing the mess.
> - old: bogus mix of spellings of "unsigned".  Here u_ is used in one place
>   and "unsigned" in another place.  rand.c uses "unsigned" with "long" in
>   most places, but it is the "unsigned" form that is the style bug --
>   in rev.1.1, u_int and u_long were used consistently.

I don't plan to touch all old style bugs right now, but I'll fix new one
you notice.

> Previous breakage of this is still not fixed.  Old versions used
> /dev/random and had error handling involving use of the current
> time when _read() failed.  

This specific sysctl() can't fail. You'll better to discuss this matter
with the original change author, not with me.

> They also spelled read() correctly,
> so that the Standard library function rand() is not broken is
> the application is a pure C90 one that supplies its own read().
> The above has doesn't even have error checking, and is broken
> if the application supplies its own sysctl().  

libc have a lot of places where it uses sysctl() instead of _sysctl().
If you assume to change them all, it will be sweep change not for me,
please ask someone else.

> Style bug: the API name 'sranddev()' is bogus for a function that doesn't
> used /dev/random like it used to.

This is historical thing when all we have was /dev/random.

-- 
http://ache.vniz.net/
bitcoin:13fGiNutKNHcVSsgtGQ7bQ5kgUKgEQHn7N