: On Wed, 26 Jun 1996 15:12:14 +0200, Andries.Brouwer@cwi.nl said:
: > Stephen Tweedie:
: > : 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.
No, but I only said that by changing an include you define an environment
where dev_t is 32 bits and it is possible to test strict conformance of
a program. You can leave it like that, and then this program will be unable
to stat files with a large st_dev or st_rdev, or recompile it in an
environment where dev_t is larger. For off_t the same holds.
: > [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.
I mean what you see at present: dev_t is 16 bits, but the stat structure
also contains 16 bit padding.
It is easier on the kernel source when the dev_t field in the stat structure
as used by the kernel (for the versioned stat system call) has a known length,
for example 64 bits.
The version given as argument in the stat call will tell
how major and minor should be distributed in these 64 bits. For example,
the version might ask to put major+minor in the low order 32 bits,
in case the application was compiled in an environment where dev_t has 32 bits.
If this doesn't fit this versioned stat will return some error like E2BIG.
: > 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.]
I think you started misunderstanding, and ended up understanding what
I meant. Yes, it is possible with one single version of libc to support
various sizes of dev_t (and of off_t), provided that the include files
define the version of stat etc that has to be used.
Andries