From owner-freebsd-arch Fri Oct 26 23:36:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id CF38A37B406; Fri, 26 Oct 2001 23:36:44 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9R6aik43419; Fri, 26 Oct 2001 23:36:44 -0700 (PDT) (envelope-from dillon) Date: Fri, 26 Oct 2001 23:36:44 -0700 (PDT) From: Matthew Dillon Message-Id: <200110270636.f9R6aik43419@apollo.backplane.com> To: Mike Smith Cc: arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 References: <200110270240.f9R2eGv07017@mass.dis.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Just to clarify, based on Peter's last mail. : :The proposal is not to change the size of time_t on x86, merely to :select a suitable size on new platforms so that we migrate in a :suitable fashion. : :This is fine, and a sensible idea. No, the current proposal... the one that has the most support (even if you discount me), is that we do not change time_t in 4.x, but in 5.x we change it to a 64 bit integer on all platforms (including IA32). This version has support from several camps. A bunch of 5.x guys like it because it means that all the 64 bit issues can be worked out by the larger community running on standard intel platforms. Other people like it because it (obviously) solves the 2038 problem. DES and I have allocated time to work on it starting mid-november. Nobody else has comitted time yet. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message