Date: Sat, 2 Jun 2001 16:21:37 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: "David O'Brien" <obrien@FreeBSD.ORG> 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: <200106022321.f52NLbu05712@earth.backplane.com> 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> <20010602142011.N31257@dragon.nuxi.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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106022321.f52NLbu05712>