From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Re: master d0c77a1: Remove some assumptions about timestamp format Date: Wed, 26 Sep 2018 11:24:51 +0200 Message-ID: <87o9ck6270.fsf@gmx.de> References: <20180925021527.10418.61555@vcs0.savannah.gnu.org> <20180925021528.9A119204E8@vcs0.savannah.gnu.org> <87bm8lanwu.fsf@gmx.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1537953789 25208 195.159.176.226 (26 Sep 2018 09:23:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 26 Sep 2018 09:23:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 26 11:23:05 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g562C-0006Sm-8s for ged-emacs-devel@m.gmane.org; Wed, 26 Sep 2018 11:23:04 +0200 Original-Received: from localhost ([::1]:57232 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g564I-0002zP-Kt for ged-emacs-devel@m.gmane.org; Wed, 26 Sep 2018 05:25:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39225) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g5646-0002yT-Qz for emacs-devel@gnu.org; Wed, 26 Sep 2018 05:25:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g5642-0001jw-RN for emacs-devel@gnu.org; Wed, 26 Sep 2018 05:25:02 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:55227) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g5642-0001jD-I1 for emacs-devel@gnu.org; Wed, 26 Sep 2018 05:24:58 -0400 Original-Received: from detlef.gmx.de ([212.86.60.15]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LwJFG-1fhY8B204M-0187B0; Wed, 26 Sep 2018 11:24:53 +0200 In-Reply-To: (Paul Eggert's message of "Tue, 25 Sep 2018 18:09:39 -0700") X-Provags-ID: V03:K1:JdMZoV61pupNb4tn6CCSDuWCYItC19mDgndGiMKh8XJWPwzgppn WJevlims9JBmA8vQP30lv8W6R7zroqNJY8iXe11a/VMf+lBm9qm5fqS0Qsqr+LOr1Pafyx/ SLQlDmwD+OlSjj1KwBGWnDYRSnEHtzvBbAiODAToWSvCmqLyMz8+ZHLJIT8Du4UuH+4oK9R nlioAb9lEjbJrynDZNvJA== X-UI-Out-Filterresults: notjunk:1;V01:K0:k1v0kZdVc4U=:Oaixwyb4Oogn2EtDA2zMNZ NmVLH8KaQfu1XOwf+sIlK/LFjy55GTUaePXhRQLIq4+azOhu9pEPDVbC2Re6ODEn4RsuqxX3N d8UNQOLJJbsWWqEs9M87ZRlj612rUey8vXNzYAZTSkMdw9hpvu2zg6onUkBWcvyJh1Q4AXoAJ G7FLQCxij0jhrRh/P9+lEfn00FjZarkfvJsABllJ5XTucwnIdAnQCe8idKhuppjx8/pWEe4H5 zvDUs+cgBLtOebfuArtOcMXZp3vRqmEcClZBpiVGJu9YPjTMt5zJWFnKV1VM4hxtUMlj+sQ9b DAiYo0lVYbONZYhPWawjv1nFS6G+ulnqBhP1CZYlw3QensUMhEMFEu0feFks/i1iaLo6Yb7i6 Vb+wZOFiUTgkJnrdjMK4r/Y4u9QmzUyt4JM7BbsTx/z2ia0L8JOzRccxvFAOVopth3+XgrtzJ 9tqPp/z9HGFaxnsT2/jAEA17UFW8pS3CL4CUDn5O6nZZd4oNmEvJoZ5fkOTn+4bibT9zyTS5l ah3yDSTEyfAos/G0PdOyQy5SzBQWvkrq0WoFxIWESAWIMnuubmW8M0LY5Ptvigaysad1xyqZg VmebEb0vbAciBvnaQoaZUb0joovSSTQQKycDOb7DSBW64s157F27jFkPx6n51tLOefpyuM00S vncn+aDqrakiuPmXoDEOfGsqDWvHUiKd+W35n0TrZ0gVOaxAspUgArHPYfGUeaXecz9/OjW7l 5XkNO/YtHotgb9IxIaPICdqy3eUkrIpQECNJ6eJFjb7Cv+vzNfGaIZk5bFy7B87Oakab8G1j X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.18 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:230079 Archived-At: Paul Eggert writes: Hi Paul, > A constant like that would make things clearer, yes. Either 0 or (0 0 > 0 0) or (0 0) should do, so I suggest just 0 as it's simplest. While > you're at it, you might consider changing the number from 0 to a > negative value, say -1 (the value that POSIX uses for invalid time_t), > since that's less likely to collide with actual file timestamps > (timestamp 0 is far more common than timestamp -1 in real filesystems > in my experience). There is already invalid_timespec() in systime.h. What about the following patch? --8<---------------cut here---------------start------------->8--- diff --git a/src/editfns.c b/src/editfns.c index 8c7491beed..fc076a52c1 100644 --- a/src/editfns.c +++ b/src/editfns.c @@ -1592,6 +1592,10 @@ static Lisp_Object time_arith (Lisp_Object a, Lisp_Object b, struct lisp_time (*op) (struct lisp_time, struct lisp_time)) { + if (!NILP (Ftime_equal_p (a, Vinvalid_time)) || + !NILP (Ftime_equal_p (b, Vinvalid_time))) + return Vinvalid_time; + int alen, blen; struct lisp_time ta = lisp_time_struct (a, &alen); struct lisp_time tb = lisp_time_struct (b, &blen); @@ -1620,6 +1624,7 @@ time_arith (Lisp_Object a, Lisp_Object b, DEFUN ("time-add", Ftime_add, Stime_add, 2, 2, 0, doc: /* Return the sum of two time values A and B, as a time value. A nil value for either argument stands for the current time. +If time value A or B is equal to `invalid-time', this value is returned. See `current-time-string' for the various forms of a time value. */) (Lisp_Object a, Lisp_Object b) { @@ -1630,6 +1635,7 @@ DEFUN ("time-subtract", Ftime_subtract, Stime_subtract, 2, 2, 0, doc: /* Return the difference between two time values A and B, as a time value. Use `float-time' to convert the difference into elapsed seconds. A nil value for either argument stands for the current time. +If time value A or B is equal to `invalid-time', this value is returned. See `current-time-string' for the various forms of a time value. */) (Lisp_Object a, Lisp_Object b) { @@ -1652,6 +1658,19 @@ See `current-time-string' for the various forms of a time value. */) ? Qt : Qnil); } +DEFUN ("time-equal-p", Ftime_equal_p, Stime_equal_p, 2, 2, 0, + doc: /* Return non-nil if time value T1 is equal to time value T2. +A nil value for either argument stands for the current time. +See `current-time-string' for the various forms of a time value. */) + (Lisp_Object t1, Lisp_Object t2) +{ + int t1len, t2len; + struct lisp_time a = lisp_time_struct (t1, &t1len); + struct lisp_time b = lisp_time_struct (t2, &t2len); + return + a.hi == b.hi && a.lo == b.lo && a.us == b.us && a.ps == b.ps ? Qt : Qnil; +} + DEFUN ("get-internal-run-time", Fget_internal_run_time, Sget_internal_run_time, 0, 0, 0, @@ -2287,6 +2306,9 @@ the TZ environment variable. It can also be a list (as from without consideration for daylight saving time. */) (Lisp_Object specified_time, Lisp_Object zone) { + if (Ftime_equal_p (specified_time, Vinvalid_time)) + check_time_validity (0); + time_t value = lisp_seconds_argument (specified_time); timezone_t tz = tzlookup (zone, false); @@ -5661,6 +5683,10 @@ it to be non-nil. */); binary_as_unsigned = true; #endif + DEFVAR_LISP ("invalid-time", Vinvalid_time, + doc: /* An invalid time value, used as "Don't know" value. */); + Vinvalid_time = make_lisp_time (invalid_timespec ()); + defsubr (&Spropertize); defsubr (&Schar_equal); defsubr (&Sgoto_char); @@ -5734,6 +5760,7 @@ it to be non-nil. */); defsubr (&Stime_add); defsubr (&Stime_subtract); defsubr (&Stime_less_p); + defsubr (&Stime_equal_p); defsubr (&Sget_internal_run_time); defsubr (&Sformat_time_string); defsubr (&Sfloat_time); --8<---------------cut here---------------end--------------->8--- > The Tramp code shouldn't care whether the constant is 0 or (0 0) or (0 > 0 0 0) [or -1 or (-1 65535) or (-1 65535 0 0)], because the code > should compare time stamps via time-less-p (or float-time, if the > timestamps are known to be small like 0 or -1, or maybe we should add > time-equal?), not via 'equal'. The idea is that the Lisp timestamp > format has changed in the past and is likely to change in the future > and one should not assume any particular format if one wants the code > to be portable. Tramp would use only `invalid-time' and `time-equal-p', agnostic to their implementations. Plus some compatibility code for older Emacsen. Best regards, Michael.