fts(3) patch for review
gcorcoran at rcn.com
Mon Jun 18 22:10:05 UTC 2007
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...
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
> 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).
More information about the freebsd-current