fts(3) patch for review
yar at comp.chem.msu.su
Wed Jun 20 10:17:12 UTC 2007
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. :-)
More information about the freebsd-current