On Wed, 26 Jun 1996 15:12:14 +0200, Andries.Brouwer@cwi.nl said:
> Stephen Tweedie:
> : On Sat, 22 Jun 1996 21:06:39 +0200, Andries.Brouwer@cwi.nl said:
> : > Eric Youngdale:
> : > POSIX requires dev_t to be an arithmetic type (so it cannot be a struct),
> : 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.
No, not easily. "gcc -ansi -pedantic-errors" will NOT give you any
way of declaring a 64-bit arithmetic type on Intel.
> [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,
What do you mean by padding? dev_t cannot include padding fields, as
it must be an arithmetic type. It can't necessarily include padding
bits, due to the ansi compiler 32-bit limit.
> 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).]
Now, if we were to create entirely separate environments in libc for
16, 32 or 64 bit dev_t's, this would work. I really do think it's
just a little bit untidy, though... :) [Having said that, it's quite
similar to what I'll have to do anyway to get the 64bit file api
working.]
Cheers,
Stephen.
-- Stephen Tweedie <sct@dcs.ed.ac.uk> Department of Computer Science, Edinburgh University, Scotland.