Re: Migrating to larger numbers

[david parsons]

In article <linux.kernel.7jhnf3$842$[e-mail]>,
H. Peter Anvin <[e-mail]> wrote:
>Followup to:  <7jhku8$[e-mail]>
>By author:    o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s (david parsons)
>In newsgroup: linux.dev.kernel
>> >
>> >Guess what?  We *ALREADY* depend on these -- dev_t in libc6 is a
>> >64-bit number.
>> 
>>     Libc6 is an wad of regrettable design decisions that, fortunately,
>>     are not yet required to run a Linux kernel.
>> 
>>     Converting dev_t into a 64 bit number (and thus making an earlier
>>     regrettable design decision -- having the filesystem contain magic
>>     numbers for device access -- into a regrettable design decision that's
>>     buttressed by nonstandard GNU constructs) is comparable to putting
>>     the Mississippi in concrete culvert because it overflowed levees
>>     that were put up to make the floodplain safe for subdivisions.
>> 
>
>Oh puh-leeze.  C9x is in final balloting, and it is very likely it
>will pass.

      Okay.  "nonstandard today, but soon it will be part of some standard"

>gcc has supported a 64-bit type forever; there is no other
>compiler that can compile libcX for X < 6 either (the headers are full
>of gcc-specific constructs), so you can go around play with libc4 all
>you want, but you're still going to need gcc.

      To compile anything?  So if I'm using lcc to build applications,
      I'll just have to toss it and replace it with gcc?   That is, in
      the words of the immortal bard, less than optimal.   (I have the
      same objection to 64-bitification of time_t; I'd much rather see
      time_t become a struct timeval or some similarly opaque type that
      doesn't depend on changing the definition of the C language.)

>This is silly.

      Well, that statement I can agree with.  But probably not in the
      way you'd want.

                  ____
    david parsons \bi/ I've got a few things to say about the existing
                   \/        headers, but that's why G-d invented perl.