Date: Wed, 20 Jun 2007 14:17:08 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Tim Kientzle <kientzle@freebsd.org> Cc: Gary Corcoran <gcorcoran@rcn.com>, current@freebsd.org Subject: Re: fts(3) patch for review Message-ID: <20070620101708.GD29685@comp.chem.msu.su> In-Reply-To: <4678C5EE.7050402@freebsd.org> References: <20070618202758.GA16711@comp.chem.msu.su> <4676FD4F.3030302@rcn.com> <20070618225134.GA18473@owl.midgard.homeip.net> <20070619141545.GB29685@comp.chem.msu.su> <4678C5EE.7050402@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070620101708.GD29685>