Date: Sun, 16 Aug 1998 00:45:17 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: ac199@hwcn.org Cc: tlambert@primenet.com, grog@lemis.com, mph@pobox.com, brawley@camtech.com.au, hackers@FreeBSD.ORG Subject: Re: 64-bit time_t Message-ID: <199808160045.RAA15910@usr07.primenet.com> In-Reply-To: <Pine.BSF.3.96.980815184549.1275A-100000@localhost> from "Tim Vanderhoek" at Aug 15, 98 07:19:50 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808160045.RAA15910>