From owner-freebsd-stable@FreeBSD.ORG Wed Dec 22 03:16:17 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B46F516A4CE for ; Wed, 22 Dec 2004 03:16:17 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7374643D31 for ; Wed, 22 Dec 2004 03:16:17 +0000 (GMT) (envelope-from craig@feniz.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 412162AA7B; Tue, 21 Dec 2004 21:16:17 -0600 (CST) Date: Tue, 21 Dec 2004 21:16:15 -0600 From: Craig Boston To: Peter Jeremy Message-ID: <20041222031614.GA29058@nowhere> Mail-Followup-To: Craig Boston , Peter Jeremy , Pete French , stable@freebsd.org References: <6.2.0.14.2.20041219181710.062cde10@localhost> <20041221185914.GL79646@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041221185914.GL79646@cirb503493.alcatel.com.au> User-Agent: Mutt/1.4.2.1i cc: stable@freebsd.org cc: Pete French Subject: Re: Will there be a 5.3.1? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2004 03:16:17 -0000 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