Subject: Re: Watch out for lseek and stat struct st_size fields!
To: None <>
From: None <>
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.