svn commit: r252608 - in head: include lib/libc/stdlib
ache at freebsd.org
Thu Jul 4 03:35:31 UTC 2013
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
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
> 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.
More information about the svn-src-head