From owner-freebsd-current@FreeBSD.ORG Wed Jun 20 10:17:12 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CFEE916A400; Wed, 20 Jun 2007 10:17:12 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 2F64013C48C; Wed, 20 Jun 2007 10:17:11 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l5KAH9EH045587; Wed, 20 Jun 2007 14:17:09 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l5KAH958045586; Wed, 20 Jun 2007 14:17:09 +0400 (MSD) (envelope-from yar) Date: Wed, 20 Jun 2007 14:17:08 +0400 From: Yar Tikhiy To: Tim Kientzle Message-ID: <20070620101708.GD29685@comp.chem.msu.su> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4678C5EE.7050402@freebsd.org> User-Agent: Mutt/1.5.9i Cc: Gary Corcoran , current@freebsd.org Subject: Re: fts(3) patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2007 10:17:12 -0000 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 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