Date: Mon, 28 Jan 2008 19:39:06 +0300 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, David O'Brien <obrien@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: <20080128163906.GR49535@comp.chem.msu.su> In-Reply-To: <20080128091747.GP48382@server.vk2pj.dyndns.org> References: <200801261709.m0QH9f2D024309@repoman.freebsd.org> <20080127043334.GA75235@dragon.NUXI.org> <20080127053813.GH49535@comp.chem.msu.su> <20080127094653.GA74753@dragon.NUXI.org> <20080128053514.GK49535@comp.chem.msu.su> <20080128091747.GP48382@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 28, 2008 at 08:17:47PM +1100, Peter Jeremy wrote: > On Mon, Jan 28, 2008 at 08:35:15AM +0300, Yar Tikhiy wrote: > >On Sun, Jan 27, 2008 at 01:46:53AM -0800, David O'Brien wrote: > >> $ find /usr/src/sys -name \*.[ch] -a -type f \ > >> | xargs grep int[0-9][0-9]_t | wc -l > >> 37026 > >> > >> I think that shows we can depend on int64_t existing and usable. > > My count (using ports/devel/id-utils) says there are 627 references to > int64_t in the tree - half of them in sys. If you extend this to > tokens matching /int[0-9]+_t$/ then those numbers go up to 62958 and > 48559 respectively. > > A more suitable type might be intmax_t - which is also used more > commonly in userland than int64_t. The range of intmax_t guaranteed by C99 is not greater than that of long long. Intmax_t is there not to store astronomical numbers, but to be able to keep a value from any non-basic integer type, e.g., when one needs to printf(3) an off_t. > >Userland code should be portable and useful to other systems in the > >chosen domain of compatibility, e.g., C99 or POSIX, unless there > >are substantial reasons for it not to. That's how different projects > >can benefit from each other's work. > > I would prefer to see the primary driver for FreeBSD code be FreeBSD, > not what other projects may or may not choose to copy from it. In > general, porting code to other systems is going to require more than > a copy-and-paste. Requiring the target system to provide a single, > fairly well-defined standard type does not seem overly onerous. I'd put it the other way around: porting code often is so painful because many people care only about their favourite systems and platforms. -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080128163906.GR49535>