>>>> 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.
Meaning either:
dev_t is 64-bit, but only 48 bits are ever used. The kernel
splits it up as junk:major:minor and complains if junk != 0.
Or:
Various structs are declared using "long long" inside of #ifndef.
Pure ANSI code gets a substitute struct with the same alignment,
a small dev_t, and padding next to the small dev_t. Most programs
will work just fine with the fake struct. Just don't compile tar
or cpio that way because then your backups of /dev are useless.
>> 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).]
Hmmm, the second meaning I think.
> 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.]
There is already room for a 32-bit dev_t in the existing structs.