Messages in this thread |  | | Date | Sat, 29 Jun 1996 11:00:07 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: SCSI device numbering (was: Re: Ideas for v2.1 |
| |
On Fri, 28 Jun 1996, Stephen C. Tweedie wrote: > > > 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.
Actually, the best solution is to just modify gcc a bit to know more about the __extension__ keyword, and then make that keyword work correctly with -ansi -pedantic. We _can_ ask for those kinds of changes to gcc, and I suspect gcc maintainers would even be willing to make them.
Gcc _already_ has a "__extension__" keyword that can be used to shut up warnings for cases where we want to use gcc extensions. You can write header-files like this, for example (try it with and without the __extension__ to see what it does):
#define strange(x) (__extension__({ int y = x; if (y) y = 2; y; }))
So the gcc developers already _do_ support silent extensions like that, it's just a pity the "__extension__" keyword doesn't work in type definitions..
Anyway, I think we should be ok with a 12+20 bit dev_t, that sounds like the best solution right now.
Linus
|  |