From owner-freebsd-hackers Sat Aug 15 17:46:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA10708 for freebsd-hackers-outgoing; Sat, 15 Aug 1998 17:46:09 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA10700 for ; Sat, 15 Aug 1998 17:46:07 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id RAA00731; Sat, 15 Aug 1998 17:45:36 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpd000676; Sat Aug 15 17:45:29 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id RAA15910; Sat, 15 Aug 1998 17:45:17 -0700 (MST) From: Terry Lambert Message-Id: <199808160045.RAA15910@usr07.primenet.com> Subject: Re: 64-bit time_t To: ac199@hwcn.org Date: Sun, 16 Aug 1998 00:45:17 +0000 (GMT) Cc: tlambert@primenet.com, grog@lemis.com, mph@pobox.com, brawley@camtech.com.au, hackers@FreeBSD.ORG In-Reply-To: from "Tim Vanderhoek" at Aug 15, 98 07:19:50 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > The difference between accuracy and precision is often hard to grasp. > > Actually, it's high-school science, now. At least around here. :) It's the secret they tell you after you get your PhD, here in the US... > > The value of time_t is as a monoclock value; ie: what it calls > > "seconds" are actually "ticks", and it is useful to know "how many > > ticks between X and Y" for things like making makefiles work. > > Do you mean for dependencies? They would work just as well if > the filesystem stored accurate time information (although fs size > might increase). :) Make dependencies. In effect, if you create an object at the same second as the source was modified, you may be hurt. This is a practical impossibility, for all but machine generated source files. For those, the penalty is that when you type "make" again, an unnecessary compilation of an object may occur to make it "at least one second older". The FS layout is not permitted to change; that's one of our major constraints. Can you imagine "well, we converted 98% of your hard drive, but you don't have room for these new indows here...."? > Of course, any system trusting time data to store ordering > information is subject to the timer's resolution. Ideally, the > filesystem needs to provide an alternate way of storing this > information. On-or-after laways works, and would result only in extra builds. If your builds are subsecond, what do you care? 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message