Date: Sat, 2 Jun 2001 15:33:03 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Matt Dillon <dillon@earth.backplane.com>, "David O'Brien" <obrien@FreeBSD.ORG> Cc: David Wolfskill <david@catwhisker.org>, arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong Message-ID: <p05100e0fb73ee9d458f7@[128.113.24.47]> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05100e0fb73ee9d458f7>