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>