|
From: | Paul Eggert |
Subject: | Re: master d0c77a1: Remove some assumptions about timestamp format |
Date: | Fri, 28 Sep 2018 10:27:39 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |