Date: Sun, 27 Jan 2008 08:38:13 +0300 From: Yar Tikhiy <yar@comp.chem.msu.su> To: "David O'Brien" <obrien@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src UPDATING src/include fts.h src/lib/libc/gen Makefile.inc Symbol.map fts-compat.c fts-compat.h fts.3 fts.c src/sys/sys param.h Message-ID: <20080127053813.GH49535@comp.chem.msu.su> In-Reply-To: <20080127043334.GA75235@dragon.NUXI.org> References: <200801261709.m0QH9f2D024309@repoman.freebsd.org> <20080127043334.GA75235@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 26, 2008 at 08:33:34PM -0800, David O'Brien wrote:
> On Sat, Jan 26, 2008 at 05:09:41PM +0000, Yar Tikhiy wrote:
> > o For things that should be at least 64 bits wide, use long long
> > and not int64_t, as the latter is an optional type.
>
> I don't follow - int64_t is an ISO-C99 type, and we have it in FreeBSD.
> Is this code expected to be taken from FreeBSD and used in some pre-C99
> system?
C99 explicitly says that any intN_t is an optional type[0]. E.g.,
a 96-bit system may choose not to provide int64_t if none of its
basic C types is 64 bits wide. fts(3) is a purely userland library
which need not depend on a particular platform[1], so I did my best
to avoid any assumptions like, `There will never be a 96-bit system
around.'
[0] In my copy of N869 Draft it's in section 7.18.1.1, paragraph 3.
[1] Unfortunately, a lot of nonportability has crept into our
implementation of it.
--
Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080127053813.GH49535>