: On Sat, 22 Jun 1996 21:06:39 +0200, Andries.Brouwer@cwi.nl said:
: > Eric Youngdale:
: > : .... Clearly a larger
: > : dev_t is needed, no matter how we do it. We need to somehow agree on how
: > : large this needs to be, and *then* we need to fix the filesystems so that
: > : they store a dev_t that is this large.
: > Yes. I think we do not have very much choice:
: > POSIX requires dev_t to be an arithmetic type (so it cannot be a struct),
: > which on Intel limits us to 64 bits.
: > Since changing is slow and painful it seems a bad idea to go to 32 bits
: > and have to change again a few years later.
: > On the other hand, not many C compilers support long long, so a 64-bit
: > dev_t would limit us to gcc. I don't know whether that would be a
: > problem for anybody.
: One word of warning --- this will break POSIX. "gcc -ansi
: -pedantic-errors" will not compile code with long long declarations.
: Any truly, strictly ANSI environment won't be able to compile programs
: referencing a 64-bit dev_t.
Yes, but that can be repaired just by changing an include file.
[The implementation I have in mind goes like this:
dev_t has 64 bits.
If the top 32 are nonzero then we actually have 64 bits, split 16+48, say.
If the top 32 are zero, but the following 16 are nonzero, then we
actually have 32 bits, split 12+20, say.
Otherwise we have 16 bits, split 8+8.
(Code somewhat similar to this can already be found in the kernel.)
If an include file defines dev_t as short+48 bits of padding,
or as int+32 bits of padding, programs will compile in a strict
environment, and actually function, except of course that programs
compiled that way cannot access devices with large dev_t, and stat()
would fail with E2BIG or so, just like stat() will fail on files
that are too large (with EFBIG or so).]
Andries