Re: fts(3) patch for review

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 <fts.h> 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_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"

-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013_at_student.uu.se