From owner-freebsd-arch Wed Oct 16 11:15: 4 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF1F137B401 for ; Wed, 16 Oct 2002 11:15:03 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49AD543E6E for ; Wed, 16 Oct 2002 11:15:03 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0308.cvx40-bradley.dialup.earthlink.net ([216.244.43.53] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 181shB-0003uo-00; Wed, 16 Oct 2002 11:15:01 -0700 Message-ID: <3DADAC5D.B3D9105B@mindspring.com> Date: Wed, 16 Oct 2002 11:13:49 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gary Thorpe Cc: freebsd-arch@freebsd.org Subject: Re: short uid/gid References: <20021016173858.98439.qmail@web11205.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Gary Thorpe wrote: > I am not aware of the latest ISO C standards, but I believe things like > 'int' and 'long' are not defined in their lengths, but the minimum > values they can represent: 'int' has to be able to do -65536 to +65536 > approximately and long has to be able to do -2 billion to +2 billon > approximately. On gcc x86, a 'long' may in fact be the same lentgh as > an 'int'. The only types in C that *may* have their lengths defined are > 'char' (8-bit value) and 'wchar' (16-bit value) as far as I know. I > believe Java has the strict length interpritations. > > Has this changed with the latest C standards (and was it ever true in > the first place)? No. Definition of atomic types is not really relevent, in this case, since we can ignore it because of the compiler/platform we are using. It's an orthogonal issue. The problem at hand is one of historically exposed interfaces, and hostorical mixing of sizes for supposedly uniformly sized values in the FreeBSD ABI, as exposed data interfaces (in files and/or in data that gets copied in and out of the kernel). In particular, it's possible to drop legacy support from the ABI, using a non-intersection approach, but not possible, using the Linux approach, unless we also adopt the user space dual library ABI symbol decoration, at the same time (or do what Windows does, with their "IUnknown" mechanism for interface versioning of libraries). An approach that makes us carry legacy interfaces forward in user space for all time is a bad approach. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message