From owner-svn-src-head@FreeBSD.ORG Thu Jul 4 03:35:31 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5F418C37 for ; Thu, 4 Jul 2013 03:35:31 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id DB5FE196C for ; Thu, 4 Jul 2013 03:35:30 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id z5so789926lbh.7 for ; Wed, 03 Jul 2013 20:35:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding:x-gm-message-state; bh=CvRgcAGrvv2FG6l00/pqVPDAfdBfOd1BLkeG+s4tuaw=; b=SgjHm0HOspatPzHp+jLQHStv8tEiA4AKMb1hw08TFGMttYIN0i/3KQBKakM097ldv/ VtwCDRr47cU/aF3O3oKCoDtBJle5+WhCCi4bGW+lmPHiq2pQy4P3Tmsouf4bewxOY+ex SoPxt6zFrHFvWtxJjzhMrbGyX5WDw8OxB/LCpjiqoGYUlmdVJL46DGY/oJFh3qnbN+G6 OCMA0ppDvC8OpWdfk466SC/R2w4UkMm5yWc8MAcYQ6bmjqoS1rzsNPWGtXQBw7hr9BL2 hnyEXsm/pTxI66EQbicZ3ddcaIih3CnQkYUk8foaNm/Nq3ZWujO3SuZ+cC+k7JjmyWhB DEoQ== X-Received: by 10.152.25.135 with SMTP id c7mr1824095lag.39.1372908929384; Wed, 03 Jul 2013 20:35:29 -0700 (PDT) Received: from [192.168.1.2] ([89.169.163.3]) by mx.google.com with ESMTPSA id i9sm298734lai.4.2013.07.03.20.35.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Jul 2013 20:35:28 -0700 (PDT) Message-ID: <51D4ED7F.5050800@freebsd.org> Date: Thu, 04 Jul 2013 07:35:27 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bruce Evans Subject: Re: svn commit: r252608 - in head: include lib/libc/stdlib References: <201307032121.r63LLtkk022011@svn.freebsd.org> <20130704120336.G1176@besplex.bde.org> In-Reply-To: <20130704120336.G1176@besplex.bde.org> OpenPGP: id=964474DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmPj1wn3n46uFY3FdO/1d/sII4opT+mK4SKL0dczWCe+lnIAW2JFc81RFdsZyTzSBqU63Nn Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 03:35:31 -0000 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