From owner-freebsd-arch Sat Oct 27 20:10:38 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id D5A2E37B406 for ; Sat, 27 Oct 2001 20:10:34 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id f9S3AX088632; Sat, 27 Oct 2001 20:10:33 -0700 (PDT) (envelope-from dillon) Date: Sat, 27 Oct 2001 20:10:33 -0700 (PDT) From: Matthew Dillon Message-Id: <200110280310.f9S3AX088632@apollo.backplane.com> To: Garrett Wollman Cc: arch@FreeBSD.ORG Subject: Re: time_t not to change size on x86 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> 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 : :< 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message