From owner-freebsd-arch Sat Oct 27 10: 6: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 2E50B37B403; Sat, 27 Oct 2001 10:06:44 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9RH6ga47601; Sat, 27 Oct 2001 10:06:42 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 10:06:42 -0700 (PDT) From: Matthew Dillon Message-Id: <200110271706.f9RH6ga47601@apollo.backplane.com> To: Peter Wemm Cc: Mike Smith , arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 References: <20011027070109.D02E9380A@overcee.netplex.com.au> 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 :> > 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. :> :> I do not like it because it creates **additional** problems that will :> appear *only* on the i386. -current has got enough problems without :> bullet holes through the feet of the primary platform. :> :> I'm quite happy with changing from 'int' to 'long', but *not* quad. : :As a followup, I wont fight to the bitter end if people are really :convinced that it is a good idea and are going to firmly commit themselves :to pick up the mess in both the src and entire ports tree. That means :submitting patches back to the original distribution producers. : :But that the idea of it still gives me the creeps. I believe we'll be :chasing bugs from this for years on the i386. : :> > DES and I have allocated time to work on it starting mid-november. :> > Nobody else has comitted time yet. :> > :> > -Matt : :Cheers, :-Peter :-- :Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au I think the absolute worst that can happen is that moving time_t to 64 bits will have the same sort of impact on ports that moving off_t to 64 bits had. I don't recall the off_t change as causing any significant pain. FreeBSD had it from the get-go, but most of our ports were compiled on systems with 32 bit off_t's. I think the reason for this can be attributed towards a general shift away from K&R and towards ANSI prototypes. Simply changing time_t from an int to a long for 64 bit architectures will not lessen the amount of work required to make it work properly on 32 bit architectures 'later'. I consider the approach worthless. If we are going to change time_t we damn well ought to fix it for all architectures all at once and get it over with. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message