Date: Sun, 10 Mar 2002 17:22:14 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Garrett Wollman <wollman@lcs.mit.edu> Cc: arch@FreeBSD.org Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <3C8C06C6.5CEFF6AA@mindspring.com> References: <27966.1015713342@critter.freebsd.dk> <p05101533b8b0508ebb56@[128.113.24.47]> <200203102207.g2AM7tN11702@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C8C06C6.5CEFF6AA>