From owner-cvs-all@FreeBSD.ORG Mon Jan 28 18:49:43 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1348016A49C; Mon, 28 Jan 2008 18:49:43 +0000 (UTC) (envelope-from flata@magnesium.net) Received: from toxic.magnesium.net (toxic.magnesium.net [207.154.84.15]) by mx1.freebsd.org (Postfix) with ESMTP id E8D4413C478; Mon, 28 Jan 2008 18:49:42 +0000 (UTC) (envelope-from flata@magnesium.net) Received: by toxic.magnesium.net (Postfix, from userid 1212) id 4A8AEDA8DB; Mon, 28 Jan 2008 10:28:27 -0800 (PST) Date: Mon, 28 Jan 2008 08:28:27 -1000 From: Juli Mallett To: Yar Tikhiy Message-ID: <20080128182827.GA53020@toxic.magnesium.net> References: <200801261709.m0QH9f2D024309@repoman.freebsd.org> <20080127043334.GA75235@dragon.NUXI.org> <20080127053813.GH49535@comp.chem.msu.su> <20080127094653.GA74753@dragon.NUXI.org> <20080128053514.GK49535@comp.chem.msu.su> <86odb6usm6.fsf@ds4.des.no> <20080128161300.GP49535@comp.chem.msu.su> <86prvluc33.fsf@ds4.des.no> <20080128170128.GS49535@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080128170128.GS49535@comp.chem.msu.su> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Dag-Erling Sm??rgrav , src-committers@FreeBSD.org, cvs-all@FreeBSD.org, David O'Brien , cvs-src@FreeBSD.org Subject: Re: cvs commit: src UPDATING src/include fts.h src/lib/libc/gen Makefile.inc Symbol.map fts-compat.c fts-compat.h fts.3 fts.c src/sys/sys param.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2008 18:49:43 -0000 * Yar Tikhiy [ 2008-01-28 ] [ Re: cvs commit: src UPDATING src/include fts.h src/lib/libc/gen Makefile.inc Symbol.map fts-compat.c fts-compat.h fts.3 fts.c src/sys/sys param.h ] > You are wrong, I haven't recieved a request for back-out yet, and > I don't consider general criticism as such. You are the first one > to ask for back-out explicitly, but I don't think that your request > has enough technical grounding. Let's take this issue to core@ > then. I think you should back it out because: 1) The perceived gains do not exist: Anybody porting code is going to have to do some legwork anyway and defining a {u,}int{8,16,32,64}_t is probably one of the things they will have to do, and isn't at all difficult. 2) The actual gains do not exist: Anybody running on so quirky a system as to have a "long long" but no 64-bit type is going to have to do more than some legwork, like annotating all the pointers to note which sort of memory they're in. It is also unlikely that such a system has a need for fts(3). 3) This is a damn strange place to start a crusade: Why is your interest in fts(3) and limited to fts(3)? The portability of it borders of non-sequitur (and I suspect that your commits to it were not because you were using fts(3) elsewhere, though I suppose it is in the realm of possibility.) As fts(3) is unlikely to be used elsewhere by many people, portability isn't a prime concern (though a little of it sure is nice.) There is also not a reason why it would be portable, as we are not taking it from an externally-maintained source who wishes to keep it portable. When are you planning to sweep the tree for __FBSDID()? I've run in to that when using FreeBSD code elsewhere far more often than I've ported FreeBSD code to a system that didn't have those C99 types. 4) Other things in libc/gen use those C99 types or less portable variations on the same theme: There are 27 instances of 'int[1368]' in libc/gen -- one of them is a manpage. The manpage is for arc4random(3), which I would bet you several dollars, a couple yuan and a handful of hrivnas has been taken outside of FreeBSD by someone more times by an order of magnitude than fts(3). And it uses the even less portable old BSD types 'u_int{8,16,32,64}', which have caused me pain in the past. But I do not know many programmers who would start with FreeBSD libc with the goal of porting many parts of it who do not know how to define a type (some of them might use #define, or perl(1), but they would all get the idea.) Thanks, Juli.