From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: master d0c77a1: Remove some assumptions about timestamp format Date: Fri, 28 Sep 2018 10:27:39 -0700 Organization: UCLA Computer Science Department Message-ID: References: <20180925021527.10418.61555@vcs0.savannah.gnu.org> <20180925021528.9A119204E8@vcs0.savannah.gnu.org> <87bm8lanwu.fsf@gmx.de> <87o9ck6270.fsf@gmx.de> <83h8ia6sj6.fsf@gnu.org> <87bm8hape9.fsf@gmx.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1538156513 12736 195.159.176.226 (28 Sep 2018 17:41:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Sep 2018 17:41:53 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Cc: Eli Zaretskii , emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 28 19:41:49 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 1g5wlw-0003Cr-AI for ged-emacs-devel@m.gmane.org; Fri, 28 Sep 2018 19:41:48 +0200 Original-Received: from localhost ([::1]:44622 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g5wo2-0001xJ-Ty for ged-emacs-devel@m.gmane.org; Fri, 28 Sep 2018 13:43:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53341) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g5wnB-0000Ve-Gz for emacs-devel@gnu.org; Fri, 28 Sep 2018 13:43:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g5wYp-000759-W7 for emacs-devel@gnu.org; Fri, 28 Sep 2018 13:28:22 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:51696) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1g5wYK-0006v6-Vk; Fri, 28 Sep 2018 13:27:45 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7F4F8160FB4; Fri, 28 Sep 2018 10:27:40 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id t7xkZqPWdiij; Fri, 28 Sep 2018 10:27:39 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id ACFBB160806; Fri, 28 Sep 2018 10:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id v1scqPtnAIT4; Fri, 28 Sep 2018 10:27:39 -0700 (PDT) Original-Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 835E21605B0; Fri, 28 Sep 2018 10:27:39 -0700 (PDT) In-Reply-To: <87bm8hape9.fsf@gmx.de> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:230109 Archived-At: Michael Albinus wrote: > Indeed. A NaN is not a time value all time functions do understand. For > example, > > (current-time-string 0.0e+NaN) > => (error "Specified time is not representable") > > I believe, a special string shall be returned here, like > "Unspecified time" or so. I'm afraid that sort of thing won't do in general. For example, what would format-time-string do? Or decode-time? > Tramp will use such a constant anyway, it has taken '(0 0) until now. It > will be returned by Tramp implementations of functions like > `file-attributes' or `visited-file-modtime', and must be understood by > the calling functions. `set-file-times', for example, does not > understand this, and so do the functions in ls-lisp.el, and likely in > Lisp packages in the wild. If I understand you aright, you want a time value that will be treated as valid by standard time functions, and yet won't be a time value that any actual filesystem would return. In that case I suggest using the timestamp (0 0 0 1000) at the Lisp level. Although this is almost exactly the same time value that your Vinvalid_time code was using, it doesn't require special support at the C level. Alternatively you could use (-1 65535 999999 999999), which is exactly the same value that your C code was effectively using. However, if it's run through struct timespec by the C code it will be floored to (-1 65535 999999 999000). Also, it can have problems on platforms where time_t is unsigned, which POSIX allows, and there are a few oddball systems that do that (QNX and VMS come to mind); although I don't know whether Emacs runs on these systems it'd be better not to exclude them arbitrarily. Another option would be (0 0 0 1), but I worry that this also would not survive an internal round trip through struct timespec. All struct timespec-compatible timestamps are possible timestamps in the filesystem I use regularly (ext4). However, (0 0 0 1000) is so unlikely I don't think we need to worry about this, which is in contrast to the current Tramp usage of (0 0) which corresponds to timestamps that I have seen on real filesystems for various reasons.