From owner-freebsd-current Tue Jan 5 14:44:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA23089 for freebsd-current-outgoing; Tue, 5 Jan 1999 14:44:07 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA23072 for ; Tue, 5 Jan 1999 14:44:04 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id OAA97949; Tue, 5 Jan 1999 14:43:27 -0800 (PST) (envelope-from dillon) Date: Tue, 5 Jan 1999 14:43:27 -0800 (PST) From: Matthew Dillon Message-Id: <199901052243.OAA97949@apollo.backplane.com> To: Greg Lehey Cc: Peter Jeremy , current@FreeBSD.ORG Subject: Re: Y2K, Y 2038? Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> overly concerned :-). :> :> There was a very similar discussion some months ago regarding the :> timestamp field in the inode (on -hackers from memory). I don't :> think the discussion went anywhere fruitful. : :Part of that discussion was concerned with the fact that, correctly or :incorrectly, people use negative time_t's. This would break that for :a comparatively minor benefit. It isn't so much that people use negative time_t's as it is people comparing time_t's and assuming a *signed* result. If time_t is unsigned, the result will be unsigned. This screws up relative compares in a lot of legacy code. Neither can time_t simply magically become 64 bits on systems where it was 32 bits before - that would be a disaster. A lot of software stores time_t in binary form in databases and such - for all sorts of reasons. It would be a disaster an order of magnitude greater then the mess that occured when 4.4 first started using 64 bit file offsets and a lot of legacy software didn't compare because it manually extern'd system functions rather then #include the correct header file. I would prefer NOT making *two* hacks to the time system. We should just move to 64 bit 'ltime_t' or something like that. It is not a big deal. Then we'll have 30 years to translate the legacy time_t's useage into the new ltime_t useage. -Matt :Greg :-- :See complete headers for address, home page and phone numbers :finger grog@lemis.com for PGP public key : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-current" in the body of the message : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message