Date: Tue, 21 Dec 2004 21:16:15 -0600 From: Craig Boston <craig@feniz.gank.org> To: Peter Jeremy <PeterJeremy@optushome.com.au> Cc: Pete French <petefrench@ticketswitch.com> Subject: Re: Will there be a 5.3.1? Message-ID: <20041222031614.GA29058@nowhere> In-Reply-To: <20041221185914.GL79646@cirb503493.alcatel.com.au> References: <6.2.0.14.2.20041219181710.062cde10@localhost> <E1Cgi14-000Bav-2Q@dilbert.firstcallgroup.co.uk> <20041221185914.GL79646@cirb503493.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 22, 2004 at 05:59:14AM +1100, Peter Jeremy wrote: > One problem is that Unix first became popular (outside academia) with > the advent of the 32-bit workstations and then took off with the rise > of Linux on 32-bit i386. Lots of Unix code has never seen an environment > were sizeof(int) == sizeof(long) == sizeof(void *) isn't true. It's not just int, long, and pointers that cause problems. There is a lot of code out there that tends to play fast and loose with the other types (POSIX?) that IIRC are supposed to be "atomic" -- size_t, time_t, off_t, etc. A while back for kicks I tried to build a 32-bit ILP system that used 64-bit time_t values, just in case it managed to make it to 2038 ;) The base system was actually in really good shape to deal with it, no doubt due to the efforts on alpha and sparc64, and ISTR an effort to use 64-bit longs on i386. Ports on the other hand were a different matter entirely... time_t was bad enough. I suspect size_t and ssize_t are in even worse shape among third-party software. Though if you just change the size of "long" you probably won't run into all that. Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041222031614.GA29058>