From owner-cvs-src@FreeBSD.ORG Mon Jan 28 05:35:19 2008 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 793D716A41B; Mon, 28 Jan 2008 05:35:19 +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 B838113C447; Mon, 28 Jan 2008 05:35:18 +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 m0S5ZF63084511; Mon, 28 Jan 2008 08:35:16 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id m0S5ZFHn084510; Mon, 28 Jan 2008 08:35:15 +0300 (MSK) (envelope-from yar) Date: Mon, 28 Jan 2008 08:35:15 +0300 From: Yar Tikhiy To: "David O'Brien" Message-ID: <20080128053514.GK49535@comp.chem.msu.su> References: <200801261709.m0QH9f2D024309@repoman.freebsd.org> <20080127043334.GA75235@dragon.NUXI.org> <20080127053813.GH49535@comp.chem.msu.su> <20080127094653.GA74753@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080127094653.GA74753@dragon.NUXI.org> User-Agent: Mutt/1.5.9i 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2008 05:35:19 -0000 On Sun, Jan 27, 2008 at 01:46:53AM -0800, David O'Brien wrote: > On Sun, Jan 27, 2008 at 08:38:13AM +0300, Yar Tikhiy wrote: > > 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. > > I think this is a quite silly argument. > > $ 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. Excuse me, but did you notice that fts(3) is not a part of sys? It's generic userland code, albeit it's contaminated by system-dependent parts for performance or whatever. > > 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.' > > This is FreeBSD - not a magazine on C programming, in which examples It doesn't mean that we shouldn't learn from a good magazine on C programming. :-) > should be usable on all platforms. Given the use of intN_t in the > kernel, we already cannot boot on this future platform But let intN_t be mostly confined in the kernel and system-dependent userland code. E.g., system-dependent include files can use them to define more portable types such as ino_t, nlink_t, or whatever. 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. > Please don't un-C99 the system that folks have worked to update us to. And I've been convinced that I'm making a part of our system more compliant to C99. We must be reading different C99 standards. :-) -- Yar