[lkml]   [1999]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Migrating to larger numbers
In article <linux.kernel.7jhnf3$842$>,
H. Peter Anvin <> wrote:
>Followup to: <7jhku8$>
>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:
>> >
>> >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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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