Date: Sat, 2 Jun 2001 14:20:11 -0700 From: "David O'Brien" <obrien@FreeBSD.ORG> To: Matt Dillon <dillon@earth.backplane.com> Cc: Garance A Drosihn <drosih@rpi.edu>, David Wolfskill <david@catwhisker.org>, arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong Message-ID: <20010602142011.N31257@dragon.nuxi.com> In-Reply-To: <200106022040.f52KeSJ05088@earth.backplane.com>; from dillon@earth.backplane.com on Sat, Jun 02, 2001 at 01:40:28PM -0700 References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <p05100e0fb73ee9d458f7@[128.113.24.47]> <20010602124907.G31257@dragon.nuxi.com> <200106022005.f52K5FR04823@earth.backplane.com> <20010602131404.M31257@dragon.nuxi.com> <200106022040.f52KeSJ05088@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 02, 2001 at 01:40:28PM -0700, Matt Dillon wrote: > You have not justifed to any reasonable degree why you believe changing > time_t from a long to an int should be done. You have not argued a time_t needs to be consistent across all FreeBSD platforms. Otherwise we get in consistent behavior across our platforms. This includes both the size of it, and the spelling of the printf() format specifier. > single *functional* point for making that change beyond your commit > message, which makes no sense because the problem you site is even > *WORSE* if time_t is an int. > > I have repeateed the salient points of my argument several times now. > If you didn't read them, then I recommend you go back to my postings and > read them again. I will summarize: > > * Changing from long to int only makes the problems you site as > fixing in your commit message worse. Not better. How is it worse?!?!? You have yet to show me a compiler warning caused by this (I am sure there are some to fix); nor a piece of code that is now broken. > * The defacto standard for two decades+ is 'long'. You need a damn > good reason to change it now and so far you haven't presented one. I think I have. I would like to hear from others over the weekend what they think. > The onus of proof here is not on me, Brian, it is on you. Explain The name is O'Brien dammit. David also works. Brian and Dave do not. > * The two other platforms we have to maintain compatibility with > the most: Solaris and Linux, use 'long'. NetBSD? OpenBSD? Not > an issue for us. I *totally* disagree with your choice of who we need to maintain compatibility with the most. In fact several commits are made to make us more like NetBSD and OpenBSD. So freebsd-arch will need to decide who we should most be like. > In fact, NetBSD seems to be well on their way > to having an alternate API judging by the kernel changes they've > made. We do not want to follow that path. If they have, why don't we? > * We have the ability to stay consistent between 32 and 64 bit > platforms by defining time_t as 'long' on both, reducing portability > headaches. How is it consistent? It is consistent *only* in spelling, not storage size nor bit-wrapping characteristics. > This is what Solaris is doing. This is what Linux is > doing. This maintains a defacto standard that has been around > forever. We damn well ought to be doing it to. Should also also follow every other mistake Sun and Linux have made because they are the "defacto" standard? I see enough "defacto" standard things in the Linuxism I have to deal with daily. -- -- David (obrien@FreeBSD.org) 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?20010602142011.N31257>