Date: Sat, 27 Oct 2001 20:10:33 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 Message-ID: <200110280310.f9S3AX088632@apollo.backplane.com> References: <20011027070109.D02E9380A@overcee.netplex.com.au> <200110272007.f9RK7NG88372@khavrinen.lcs.mit.edu> <200110272029.f9RKTIi56468@apollo.backplane.com> <200110272049.f9RKn9K88676@khavrinen.lcs.mit.edu> <200110272056.f9RKuiZ64324@apollo.backplane.com> <200110272110.f9RLAeW91039@khavrinen.lcs.mit.edu> <200110272220.f9RMKmH64657@apollo.backplane.com> <200110280256.f9S2utu93282@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:<<On Sat, 27 Oct 2001 15:20:48 -0700 (PDT), Matthew Dillon <dillon@apollo.backplane.com> said:
:
:> I already responded to the C90 stuff you posted. Your reasoning
:> and the elements you posted were extremely weak arguments, frankly.
:
:As opposed to you who has never participated in the standards process?
What kind of idiotic statement is this? So only 'blessed' people
have a right to have an opinion about something? Oh please.
Your statement makes no sense at all, Garrett. Participation in
this particular standard is not a prerequisit for having a
worthwhile opinion on a section of it. The simple fact is
that the C90 element you pointed was an extremely indirect and weak
argument, and also quite out of date considering the fact that
64 bit ints on 32 bit architectures were not in common use
10 years ago. BSD actually spearheaded that with off_t.
:> So frankly, Garrett, I don't really give a damn what a ten-year old
:> standard says.
:
:And I don't care whether you care or not, Matt. It doesn't make your
:proposal anything less than monumental stupidity. It took the
:original Standard C a good FIVE YEARS to be fully accepted, and we are
:still making concessions to pre-Standard C even today. It will take
:at least as much time for C99 to be as widespread.
So let me get this straight... you are saying there is a new
standard out there that might allow this, but we shouldn't
do anything that might conform to it that might break some
other standard that is over a decade old? You are saying
we shouldn't even begin adding C99 functionality for another
3 years?
That makes no sense.
These standards are based on what people are doing in the
field... demonstarted functionality, but you are saying
that we aren't allowed to demonstrate functionality for
even the current 'new' standard by fixing an obviously
flawed type?
Again, such a position makes no sense.
:> 64 bit integer types on 32 bit platforms are totally acceptable
:> today.
:
:I never said they weren't. I said that we should not break old
:conforming Standard C applications. We have never been fully POSIX
:compliant -- the old POSIX was just too limited -- but we at least
:made an effort to support C90. You are proposing to break them, in
:order to facilitate programs which were using time_t incorrectly
:anyway.
:
:-GAWollman
I certainly am not proposing that we break them. The vast
majority of programs will still work just fine, though
without some hacking they may still fall when time overflows
a 32 bit int (which they would have anyway).
If you are going to argue that changing time_t to a 64 bit
int 'breaks' all these alleged programs, then I recommend
that you put your money where your mouth is and demonstrate
this assumption. Because so far nearly all the code I've
gone through either (A) just works with time_t as a 64 bit int,
or (B) works with time_t as a 64 bit int but truncates it
to 32 bits, leaving them no worse off then they were before.
The two pieces of code I've come across that are 'broken'
in the real sense of the word were assuming that
sizeof(time_t) == sizeof(int) (not even long!), which is
broken even under C90.
So, Garrett, put your money where your mouth is. You seem
to believe that this change will create all sorts of havoc.
Prove it, because I am looking all code some of which is
over 15 years old and I don't see it.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200110280310.f9S3AX088632>