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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
