Subject: Re: Watch out for lseek and stat struct st_size fields!
To: None <mw@eunet.ch>
From: None <rhealey@aggregate.com>
List: amiga-dev
Date: 07/13/1994 14:43:23
> *soap box on*
> _GRIN_ So, how many people had benefits so far from having a 64bit off_t OS,
> and how many suffer from the mess it caused?
> *soap box off*
>
My soapbox response:
I've lived through:
All the worlds an 8 bit Z80
All the worlds a 16 8086
All the world's a VAX
All the world's a Sun 3
All the workd's a SPARC
All the world's a 32 bit machine
with ints and pointers of the same size...
And now all the world uses 32 bit filesystem with int == pointer and
NOBODY will ever need to use 64 bit quantitys...
That current coding practices of PD/Freely redistributable programs are
poor isn't a reason to know the PROPER decision was to move to 64
bits NOW in 4.4 BSD. We'll be ahead of the others who will benifit from
our finding their sloppy code. I went through this using SVR4 from
'90 to present.
Interestingly enough, it was PD and GNU code that caused the most
headaches for SVR4, ANSI C and POSIX functionality. X programs came in
a close 2nd. People blamed it on SVR4 being "braindead". Well now those
same sorts of programs are hurling on BSD 4.4, NOT just NetBSD by the
way, and so what do way say now? That BSD 4.4 is braindead? I prefer
to blame the proper partys: The sloppy programmers who assumed all
the world's a 32 bit int and that filesystems will always be limited
to 32 bit sized files, or even UNIX type filesystems...
In the next year MIPS, SPARC, Power and probably even Intel will
start going 64 bit. Alpha is already there. It was a GOOD decision
to change to 64 bits, and boost the other fields to 32 and 16.
So far X11R5, tex and texinfo are the only applications I've been
bitten hard on. The exact same ones that bit me hard when I first
started dealing with SVR4 in '90.... My how some things change over
the years...
End smart ass/soapbox reply mode.
-Rob
------------------------------------------------------------------------------