From owner-freebsd-current@FreeBSD.ORG Mon Jun 18 23:07:19 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 797AB16A421 for ; Mon, 18 Jun 2007 23:07:19 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 067C813C46C for ; Mon, 18 Jun 2007 23:07:18 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-253-10-135.bredband.comhem.se ([83.253.10.135]:51461 helo=falcon.midgard.homeip.net) by ch-smtp01.sth.basefarm.net with smtp (Exim 4.66) (envelope-from ) id 1I0Q4Q-0004d1-3j for current@freebsd.org; Tue, 19 Jun 2007 00:51:38 +0200 Received: (qmail 70940 invoked from network); 19 Jun 2007 00:51:35 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with SMTP; 19 Jun 2007 00:51:35 +0200 Received: (qmail 18557 invoked by uid 1001); 19 Jun 2007 00:51:35 +0200 Date: Tue, 19 Jun 2007 00:51:35 +0200 From: Erik Trulsson To: Gary Corcoran Message-ID: <20070618225134.GA18473@owl.midgard.homeip.net> Mail-Followup-To: Gary Corcoran , Yar Tikhiy , current@freebsd.org References: <20070618202758.GA16711@comp.chem.msu.su> <4676FD4F.3030302@rcn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4676FD4F.3030302@rcn.com> User-Agent: Mutt/1.5.14 (2007-02-12) X-Originating-IP: 83.253.10.135 X-ACL-Warn: Too high rate of unknown addresses received from you X-Scan-Result: No virus found in message 1I0Q4Q-0004d1-3j. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1I0Q4Q-0004d1-3j 93ea34d851029601725c3c2f686659b2 Cc: Yar Tikhiy , 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 23:07:19 -0000 On Mon, Jun 18, 2007 at 05:46:55PM -0400, Gary Corcoran wrote: > 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... 'long long' is part of C99 and was widely supported by many compilers even before C99 was approved. int64_t is also part of C99. The difference is that 'long long' is guaranteed to be at least 64 bits, while int64_t (if it exists which is not guaranteed) is exactly 64 bits wide. > > 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). > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Erik Trulsson ertr1013@student.uu.se