fts(3) patch for review

[Yar Tikhiy]

On Tue, Jun 19, 2007 at 11:15:10PM -0700, Tim Kientzle wrote:
> >>>>- 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....
> >>
> >>'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 only mandatory <stdint.h> types are intmax_t and uintmax_t while
> >all the [u]intN_t types are declared optional by C99.
> 
> So why not use intmax_t?

It's a temptation that can be hard to resist.  However, it paves
the road to the sin of greed -- it's a pity there's no C commandment
for that sin yet. :-)

As far as I understand, [u]intmax_t are the types for the portable
handling of other non-basic integer types.  (In fact, nearly portable
because one still has to guess signedness in advance.)  E.g., one
can't printf an off_t portably without the help of intmax_t because
any cast to a basic C type can be rendered bogus by the next
collective advancement in computer storage and the C language.

OTOH, using [u]intmax_t alone doesn't buy much.  In the case of
fts(3), defining fts_number as intmax_t still won't allow to store
128-bit values in it reliably but it will be a clear sign that one
can't limit his appetite.  The next step would be to introduce a
small array of intmax_t's etc.  Note that FTSENT has fts_pointer
that can be used to associate any data with the entry in case one
can't get along with a basic integer.  BTW, currently fts_pointer
is overlaid by ``int64_t fts_bignum'', which is a nice vignette on
how greed can divert a developer from a thoughtful solution. :-)

-- 
Yar