lkml.org 
[lkml]   [1996]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.033 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site