From owner-svn-src-head@FreeBSD.ORG Thu Mar 24 08:47:19 2011 Return-Path: Delivered-To: svn-src-head@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id 804981065679; Thu, 24 Mar 2011 08:47:19 +0000 (UTC) Date: Thu, 24 Mar 2011 08:47:19 +0000 From: Alexander Best To: d@delphij.net Message-ID: <20110324084719.GA79493@freebsd.org> References: <201103232208.p2NM818d008805@svn.freebsd.org> <20110324002955.GA25594@freebsd.org> <4D8A9F02.6000408@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D8A9F02.6000408@delphij.net> Cc: svn-src-head@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, src-committers@FreeBSD.ORG, Xin LI Subject: Re: svn commit: r219939 - head/lib/libutil X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Mar 2011 08:47:19 -0000 On Wed Mar 23 11, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > On 03/23/11 17:29, Alexander Best wrote: > > On Wed Mar 23 11, Xin LI wrote: > >> Author: delphij > >> Date: Wed Mar 23 22:08:01 2011 > >> New Revision: 219939 > >> URL: http://svn.freebsd.org/changeset/base/219939 > >> > >> Log: > >> humanize_number(3) multiply the input number by 100, which could cause an > >> integer overflow when the input is very large (for example, 100 Pi would > >> become about 10 Ei which exceeded signed int64_t). > > > > i think we should also change the humanize_number(3) manual page accordingly. > > here's a rough draft (date not bumped, yet). > > I think matching the variables within source code would not be necessary > - -- I think it's much more clear to the reader of the manual page when > the parameter called "number" and not "quotient" when the function is > called "humanize_number". > > I am not sure about the CAVEATS part though, to me, it's kinda obvious > since a parameter of signed int64_t can represent only a maximum number > of INT64_MAX and a minimum number of INT64_MIN, and I think we don't > document these explicitly for other manual pages. Personally I am > inclined not to document this as limitation at all but would not object > doing so. those are very good arguments. you have me convinced. let's keep the manual the way it is. more so i think both your assumptions are very well suited to become a style(9) entry. i've also thought about the difference between the base 2 and base 10 values. according to the official docs we should refer to base 2 values as Ki, Mi, etc. however i don't hink this is implementable, since too much code would need to be changed. the actual problem i see is that from the output of df(1) e.g. one cannot know if base 2 or base 10 is implied. cheers. alex > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! Live free or die > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (FreeBSD) > > iQEcBAEBCAAGBQJNip8CAAoJEATO+BI/yjfBz3YH/3YDlfvf8Bty6NeBnk3CyxjE > skeaowGWIG5/gQ73zXfc1KTBEr5CobNLZWxuvGnXGCfMdATypRQR+5yQt366tQNK > oDvd60tMofztH6rtrBt9b/td2mIoQAfX9Mc0X9ri69LgkExXVQBxqAcxkYxVadGm > r+nAkhZjpaHdz20eDXbQg7wDXd3iGEBYx1wagMIBLtVeJL0GFKABXIHiZfbcBU9S > tZNlXpeF3SXqOIql9KEeJ9+Zq8neU2sE7J1y3Jph4j8kkN39CABzNNKUHH7KLl7/ > mD9mPKxILulDMkropntEU3G7uE2Y1Ax9o7PcjMbd509/bpzZK2SP4t28VSQg1/8= > =ODAn > -----END PGP SIGNATURE----- -- a13x