From owner-freebsd-arch Sat Jun 2 16:21:45 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 921B137B424; Sat, 2 Jun 2001 16:21:37 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f52NLbu05712; Sat, 2 Jun 2001 16:21:37 -0700 (PDT) (envelope-from dillon) Date: Sat, 2 Jun 2001 16:21:37 -0700 (PDT) From: Matt Dillon Message-Id: <200106022321.f52NLbu05712@earth.backplane.com> To: "David O'Brien" Cc: Garance A Drosihn , David Wolfskill , arch@FreeBSD.ORG, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong 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> <20010602131404.M31257@dragon.nuxi.com> <200106022040.f52KeSJ05088@earth.backplane.com> <20010602142011.N31257@dragon.nuxi.com> 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: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. I had to go through this rigamorale getting Diablo to work on 32 and 64 bit platforms. long is the only way to get consistent behavior across platforms and across operating systems. By making the native type for time_t be 'long' we virtually guarentee that porting problems between FreeBSD and other OS's and platforms will be minimized. But making it an 'int' virtually guarentees the reverse... now people who write code under FreeBSD may mistakenly assume that time_t can be treated as an int when, in fact, it can't, and the result will be mysterious failures and porting headaches when those people try to compile their programs on other platforms. Porting issues exist no matter how time_t is typedef'd, but they are a whole lot worse with int verses long. Your assumption that turning time_t into an int somehow makes it more consistent and better all around is severely flawed. And, for your information, NetBSD typedef's time_t as a long on IA32, not an int. It's still 32 bits on IA32 of course. But it's a long. So your changing FreeBSD's time_t to an int goes against other FreeBSD distribution's grains as well as against Linux and Solaris. NetBSD unfortunately decided to go with 32 bit time_t's on alpha and sparc64, but I don't think it is appropriate for us to follow in their footsteps there. All they are doing is creating a huge mess for themselves down the line, a mess that we can avoid if we look forward 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. Think, damn it! You site people using printf("%ld", time_t) has being an improper use of time_t and that is your excuse for turning it into an int. With it int, now people can do printf("%d", time_t) without generating a warning, which is at least as flawed as using %ld and far more likely to occur considering how much more predominately 'int' is declared in source code verses 'long'. At least with it a long people know it has to be treated specially. GCC makes a (small) distinction between int and long on 32 bit platforms precisely to generate warnings that help people with porting issues. They had to back down a bit on the warnings, but there are a few still in the compiler (like format string warnings). :> * 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 15 years we are *completely* *fucked* if we go with 32 bit time_t's on 64 bit platforms. Completely and utterly fucked. We should fix this now while we still have the chance. I do not buy any effort to try to keep time_t the same physical size between platform ports. It is a totally inappropriate argument that will only get us into major trouble down the road on 64 bit platforms. We have enough problems already figuring out how to give 32 bit platforms 64 bit time functions without breaking upgrade compatibility for major subsystems like databases. We do not need to invite the same problems on our 64 bit platform portrs. So the argument that time_t should be made a 32 bit quantity on IA32 so it can be an 'int' on 64 bit FreeBSD ports is completely bogus. If you guys want to leave the Alpha port in a screwed up 32 bit time_t state, I can't do much about it. But I do not want it to bleed over into a decision to break IA32's use of long to try to maintain compatibility with the already broken Alpha port. :> 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? off64_t ? lseek64? Do you want FreeBSD to go down the same path that SGI went down? It's been proven to be a huge fraggin mess and we absolutely do not want to follow in their footsteps. We were lucky with off_t being 64 bits... look what happened there? Do you see FreeBSD programmers using weird-looking lseek64() function calls? No. Do you honestly believe that FreeBSD coders will start using FreeBSD-only 64 bit time functions en-mass? It isn't going to happen. People will move away from our platform first and start calling it obsolete or weird. That's what happened to IRIX to a degree. :> * 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. It is consistent in source code. 'long' may mean different things on different platforms, but when writing portable source you expect it to be 32 or 64 bits and the code can be written properly to be portable without all sorts of nasty #ifdef's. That is why 'long' is more consistent across platforms for time_t purposes. People have come to use long time_t's on 64 bit platforms to solve the 203x problem because it's a whole lot easier and more portable then changing the API. : :> 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) This is one case where Sun and Linux are doing exactly the right thing. Linux learned their lessons with off_t and didn't repeat them for time_t. Solaris also learned its lessons with off_t, though many years earlier. I'll bet they wish now that they had gone to 64 bit off_t's in the CSRG 4.4 timeframe rather then the mess they wound up with! This commit you've made uses reasoning that has proven to be a mistake many times over in past years on other platforms. It needs to be backed out. And I would also strongly recommend to the Alpha people that they fix their time_t to properly use a long now. Be that as it may, my concern right now is primarily that the commit made to i386 should be backed out. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message