From owner-freebsd-arch Sun Mar 10 17:22:38 2002 Delivered-To: freebsd-arch@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 84B0B37B404 for ; Sun, 10 Mar 2002 17:22:35 -0800 (PST) Received: from pool0364.cvx22-bradley.dialup.earthlink.net ([209.179.199.109] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16kEWH-0001T0-00; Sun, 10 Mar 2002 17:22:33 -0800 Message-ID: <3C8C06C6.5CEFF6AA@mindspring.com> Date: Sun, 10 Mar 2002 17:22:14 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Garrett Wollman Cc: arch@FreeBSD.org Subject: Re: Increasing the size of dev_t and ino_t References: <27966.1015713342@critter.freebsd.dk> <200203102207.g2AM7tN11702@khavrinen.lcs.mit.edu> 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 Garrett Wollman wrote: > In article <3C8B002B.D42A8572@mindspring.com> Terry Lambert writes: > >Note also that POSIX requires them to be atomic types. So > >"long long" need not apply, FWIW. > > Methinks Terry would be well served by actually *reading* the POSIX > standard some time. Which POSIX? > What POSIX says in this timeline is that dev_t shall be an > ``arithmetic type of appropriate length''. (I.e., dev_t is allowed to > be a complex if that is the implementor's desire.) > > POSIX goes on to require that ino_t be ``an unsigned integral type''. > > POSIX has absolutely no notion of ``atomic types'' other than > sig_atomic_t. > > In other words, `long long' is a perfectly acceptable underlying type > for both dev_t and ino_t. The only other advice POSIX gives on the > subject is: I'm pretty positive that it was you who prevented us from switching over some values to time_t, based on the atomicity argument. Yes, I know "atomic" is not the correct POSIX adjective for this. > # The st_ino and st_dev fields taken together uniquely identify the > # file within the system. You can't both increase the size of the object and maintain binary compatability while satisfying this clause. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message