Re: fts(3) patch for review

On Tue, Jun 19, 2007 at 12:51:35AM +0200, Erik Trulsson wrote:
> 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.

Thank you for explaining the point!  It seems to be oft-missed that
the only mandatory <stdint.h> types are intmax_t and uintmax_t while
all the [u]intN_t types are declared optional by C99.  The [u]intN_t
types are OK in the kernel and system-specific tools but I'd rather
avoid them in pure userland code.  Not that I'm portability purist,
but portable code often proves to be better because one has to think
it over more thoroughly. :-)

The reason for [u]intN_t being optional is obvious: if a platform
provides say uint42_t, the type must behave as though it is exactly
42 bits wide, e.g., wrap around to 0 from 2^42-1.  OTOH, long long
can have any width suitable to the particular platform as long as
it meets quite loose requirements on its range from C99.

-- 
Yar