From owner-freebsd-arch Sat Jun 2 12:33:18 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 51A1537B422; Sat, 2 Jun 2001 12:33:13 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f52JX6S127618; Sat, 2 Jun 2001 15:33:06 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200106021739.f52Hd9V03943@earth.backplane.com> References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> Date: Sat, 2 Jun 2001 15:33:03 -0400 To: Matt Dillon , "David O'Brien" From: Garance A Drosihn Subject: Re: time_t definition is wrong Cc: David Wolfskill , arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 At 10:39 AM -0700 6/2/01, Matt Dillon wrote: >: >:On Sat, Jun 02, 2001 at 01:23:05AM -0700, Matt Dillon wrote: >:> Yes, I know all that. The problem isn't that you couldn't >:> have an unsigned time_t, the problem is that there are vast >:> amounts of software already out there that would "break >:> mysteriously" if you did. So, like the int<->long problem, >:> the best thing to do is not rock the boat. That means for >:> maximum portability time_t has to be a signed long. Not >:> int, not unsigned int, not unsigned long... just 'long'. >: >:There is not enough context here for me to get any idea what the >:issue is. This email argued signed vs. unsigned, and that has >:nothing to do with time_t being an int. >: >:Since on IA-32 int == long, the only issue is what ones uses in >:printf() and scanf(). I have not seen anyone having a problem >:with this yet. >: >:So I ask you to bring this up on freebsd-arch@freebsd.org why >:time_t needs to be a long. If you had more multi-platform >:concerns you would understand why having as consistent >:definitions of things is best for FreeBSD. > > Consistency is best, but breaking IA32 to match the already > broken Alpha port is the wrong solution. For consistency > we should match what Solaris, Linux, and most other UNIX > operating systems use, which is 'long'. I can't help but think that sometime soon Garrett is going to kick me off the freebsd-standards list because how often I tend to refer questions on other lists to that list. Still, it seems to me that a topic like this must come up in discussions by the standards bodies. SingleUnixSpec seems to have nothing useful to say about time_t, but maybe the latest draft of Posix does. I don't have any strong feeling about what is "right" in this case, but I do think it would be appropriate to back out the change to time_t until the question *is* correctly sorted out. This change could effect a wide variety of programs in a way which will not be immediately obvious. If what we have is wrong, then we should make the change and fix whatever breaks, but I don't think we should start that process until we KNOW that what we have (and have had for quite some time) is wrong. So, I've included freebsd-standards on this, although I wouldn't blame anyone for being exasperated with me after seeing this topic bounce across multiple mailing lists... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message