From owner-freebsd-current@FreeBSD.ORG Mon Jun 18 22:10:05 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31B5416A421 for ; Mon, 18 Jun 2007 22:10:05 +0000 (UTC) (envelope-from gcorcoran@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id EA52513C44B for ; Mon, 18 Jun 2007 22:10:04 +0000 (UTC) (envelope-from gcorcoran@rcn.com) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 18 Jun 2007 17:41:53 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.8.3-GA) with ESMTP id NLQ81623; Mon, 18 Jun 2007 17:41:53 -0400 (EDT) Received: from 207-172-55-230.c3-0.tlg-ubr5.atw-tlg.pa.cable.rcn.com (HELO [10.56.78.161]) ([207.172.55.230]) by smtp01.lnh.mail.rcn.net with ESMTP; 18 Jun 2007 17:41:45 -0400 Message-ID: <4676FD4F.3030302@rcn.com> Date: Mon, 18 Jun 2007 17:46:55 -0400 From: Gary Corcoran User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Yar Tikhiy References: <20070618202758.GA16711@comp.chem.msu.su> In-Reply-To: <20070618202758.GA16711@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr02.lnh.mail.rcn.net) Cc: current@freebsd.org Subject: Re: fts(3) patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2007 22:10:05 -0000 Yar Tikhiy wrote: > Hi all, > > Our fts(3) functions and data structures suffer from too narrow > integer types, which apparently were selected in ancient days when > RAM was costlier than gold. The consequences of that choice are > illustrated by PR bin/104458. In short, find(1) can't walk and > rm(1) can't remove file trees an ordinary user can create. > > To fix the problem, structures in have to be changed. For > my change (attached below), I chose new types using the following > principles I believe to be well-known in the C world: > > - avoid `short' unless there is a very grave reason to try to > save RAM -- on modern platforms using `short' results in larger > and slower code; > - for object sizes, use size_t unless it's 100% certain that > the object will be really small (note that fts(3) can construct > pathnames _much_ longer than PATH_MAX for its consumers); > - for variables than count simple, limited things like states, > use plain vanilla `int' as it's the type of choice in C; > - for bit flags use u_int because signed bit-wise operations > are unportable in C; > - for things that should be at least 64 bits wide, use long long > and not int64_t, as the latter is an optional type. Isn't "long long" a gcc-ism, whereas int64's are portable (posix?) standards? I don't know what the FreeBSD policy is, but for other projects that strive to be portable, including the use of non-gcc compilers, "long long" is frowned upon... Other than that, I agree with the above, except that for things which only make sense as positive numbers, such as a count, I try to use unsigned int. On modern platforms there should be no speed or RAM difference from using an int, but it makes things mildly clearer (sometimes). Gary > An open question is what type to use for the level. Since one can > chain-mount several filesystems, theoretically the level can be > greater than the maximum value of ino_t, which is 2^32-1. OTOH, I > doubt that the limit can be hit in practice, especially on 32-bit > systems, so `long' can be a fair compromise for the level. > > Comments are welcome. Thanks! > > P.S. According to my tests, the stock system tools happily build > and run with the modified fts(3). >