From owner-freebsd-arch Sat Jun 2 13:14: 9 2001 Delivered-To: freebsd-arch@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 0348A37B424 for ; Sat, 2 Jun 2001 13:14:07 -0700 (PDT) (envelope-from obrien@nuxi.ucdavis.edu) Received: from dragon.nuxi.com (root@trang.muxi.com [206.40.252.115] (may be forged)) by relay.nuxi.com (8.11.2/8.11.2) with ESMTP id f52KE5l83720; Sat, 2 Jun 2001 13:14:05 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.11.3/8.11.1) id f52KE4Z83545; Sat, 2 Jun 2001 13:14:04 -0700 (PDT) (envelope-from obrien) Date: Sat, 2 Jun 2001 13:14:04 -0700 From: "David O'Brien" To: Matt Dillon Cc: Garance A Drosihn , David Wolfskill , arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong Message-ID: <20010602131404.M31257@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <20010602124907.G31257@dragon.nuxi.com> <200106022005.f52K5FR04823@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200106022005.f52K5FR04823@earth.backplane.com>; from dillon@earth.backplane.com on Sat, Jun 02, 2001 at 01:05:15PM -0700 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 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 On Sat, Jun 02, 2001 at 01:05:15PM -0700, Matt Dillon wrote: > It is really the person making the commit (you) that has the burden > of justification here, not those of us who object to it. 1. I feel I have. You keep saying "breakage" but aren't telling me what specifically it is. You have not argued a single *functional* point here -- only the spelling of the 32-bit type used. 2. We really don't operate that way around here any more. Sad to say, but true. For some reason the burdon is now on the receiver. > Explain why you > believe changing the long to int can be justified in light of the fact > that Solaris and Linux use long (and all the other reasons I iterated!). NetBSD, OpenBSD, and HP-UX uses 32bit types for time_t. > Your reasoning so far is extremely weak and not very forward looking. Forward looking is to make time_t 'long long'. We can do that if you like. > It is certainly not sufficient to make such a basic change to a core > type stick I think! I do have backing from another committer for this. In fact one that we look to for guidance on these things. > It also seems to me that nobody has really considered what is going to > happen 15 years down the line when the importance of being able to > write 203x-safe software becomes paramount. Well, if you are concerned about 15 years from you, you would be pushing for a 'long long' time_t, not a `long' one. > The linux/Solaris/everyone-else crowd uses 'long' precisely because > they assume (rightly) that by the time it matters cpu's will be 64 bit > native. Uh.. I've got $100 that says embedded CPUs will still be 32-bit, not 64. FreeBSD does have a goal of running on some embedded CPUs -- PPC and StrongARM. -- -- David (obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message