Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Ken Brown]

On 4/27/2017 6:24 PM, Paul Eggert wrote:
> branch: master
> commit 085c7f608657d2aa19a6b2b0fe29d3deaa8eb6ff
> +  (should (string-equal
> +           (format-time-string "%Y-%m-%d %H:%M:%S %z (%Z)" '(0 0 0 0)
> +                               "NZST-12NZDT,M9.5.0,M4.1.0/3")
> +           "1970-01-01 13:00:00 +1300 (NZDT)")))

This test fails on Cygwin.

(format-time-string "%Y-%m-%d %H:%M:%S %z (%Z)" '(0 0 0 0)
		    "NZST-12NZDT,M9.5.0,M4.1.0/3")

evaluates to "1970-01-01 12:00:00 +1200 (NZST)".  Can you give me some 
guidance as to how to track this down?  I know nothing about how time 
zones work.

Ken

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Paul Eggert]

Ken Brown wrote:
> This test fails on Cygwin.
>
> (format-time-string "%Y-%m-%d %H:%M:%S %z (%Z)" '(0 0 0 0)
>             "NZST-12NZDT,M9.5.0,M4.1.0/3")
>
> evaluates to "1970-01-01 12:00:00 +1200 (NZST)".  Can you give me some guidance
> as to how to track this down?  I know nothing about how time zones work.

What does this shell command do?

TZ='NZST-12NZDT,M9.5.0,M4.1.0/3' date -d@0 +'%Y-%m-%d %H:%M:%S %z (%Z)'

On a working system with GNU 'date', it should output this:

1970-01-01 13:00:00 +1300 (NZDT)

If it outputs "1970-01-01 12:00:00 +1200 (NZST)" on Cygwin, it's a bug in Cygwin 
not in Emacs per se. If so, perhaps we should just skip the test on Cygwin (you 
might file a Cygwin bug report). If not, I'll have some other questions to ask.

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Ken Brown]

On 4/30/2017 4:49 PM, Paul Eggert wrote:
> Ken Brown wrote:
>> This test fails on Cygwin.
>>
>> (format-time-string "%Y-%m-%d %H:%M:%S %z (%Z)" '(0 0 0 0)
>>             "NZST-12NZDT,M9.5.0,M4.1.0/3")
>>
>> evaluates to "1970-01-01 12:00:00 +1200 (NZST)".  Can you give me some
>> guidance
>> as to how to track this down?  I know nothing about how time zones work.
>
> What does this shell command do?
>
> TZ='NZST-12NZDT,M9.5.0,M4.1.0/3' date -d@0 +'%Y-%m-%d %H:%M:%S %z (%Z)'
>
> On a working system with GNU 'date', it should output this:
>
> 1970-01-01 13:00:00 +1300 (NZDT)
>
> If it outputs "1970-01-01 12:00:00 +1200 (NZST)" on Cygwin, it's a bug
> in Cygwin not in Emacs per se.

It does output "1970-01-01 12:00:00 +1200 (NZST)".

> If so, perhaps we should just skip the
> test on Cygwin (you might file a Cygwin bug report).

Let's not skip it yet.  I'll file a Cygwin bug report first.

Thanks.

Ken

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Eli Zaretskii]

> From: Ken Brown <kbrown@cornell.edu>
> Date: Sun, 30 Apr 2017 17:28:58 -0400
> 
> On 4/30/2017 4:49 PM, Paul Eggert wrote:
> >
> > What does this shell command do?
> >
> > TZ='NZST-12NZDT,M9.5.0,M4.1.0/3' date -d@0 +'%Y-%m-%d %H:%M:%S %z (%Z)'
> >
> > On a working system with GNU 'date', it should output this:
> >
> > 1970-01-01 13:00:00 +1300 (NZDT)
> >
> > If it outputs "1970-01-01 12:00:00 +1200 (NZST)" on Cygwin, it's a bug
> > in Cygwin not in Emacs per se.
> 
> It does output "1970-01-01 12:00:00 +1200 (NZST)".

Perhaps that's because the DST beginning in 1970 according to these
rules is before the epoch.  I assume that this does produce "+1300"
offset with Cygwin, does it?

  TZ='NZST-12NZDT,M9.5.0,M4.1.0/3' date -d "Sep 28 1970" +'%Y-%m-%d %H:%M:%S %z (%Z)

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Ken Brown]

On 5/1/2017 11:02 AM, Eli Zaretskii wrote:
>> From: Ken Brown <kbrown@cornell.edu>
>> Date: Sun, 30 Apr 2017 17:28:58 -0400
>>
>> On 4/30/2017 4:49 PM, Paul Eggert wrote:
>>>
>>> What does this shell command do?
>>>
>>> TZ='NZST-12NZDT,M9.5.0,M4.1.0/3' date -d@0 +'%Y-%m-%d %H:%M:%S %z (%Z)'
>>>
>>> On a working system with GNU 'date', it should output this:
>>>
>>> 1970-01-01 13:00:00 +1300 (NZDT)
>>>
>>> If it outputs "1970-01-01 12:00:00 +1200 (NZST)" on Cygwin, it's a bug
>>> in Cygwin not in Emacs per se.
>>
>> It does output "1970-01-01 12:00:00 +1200 (NZST)".
> 
> Perhaps that's because the DST beginning in 1970 according to these
> rules is before the epoch.  I assume that this does produce "+1300"
> offset with Cygwin, does it?
> 
>    TZ='NZST-12NZDT,M9.5.0,M4.1.0/3' date -d "Sep 28 1970" +'%Y-%m-%d %H:%M:%S %z (%Z)

Yes, it does.

Ken

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Eli Zaretskii]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 30 Apr 2017 13:49:53 -0700
> 
> Ken Brown wrote:
> > This test fails on Cygwin.
> >
> > (format-time-string "%Y-%m-%d %H:%M:%S %z (%Z)" '(0 0 0 0)
> >             "NZST-12NZDT,M9.5.0,M4.1.0/3")
> >
> > evaluates to "1970-01-01 12:00:00 +1200 (NZST)".  Can you give me some guidance
> > as to how to track this down?  I know nothing about how time zones work.
> 
> What does this shell command do?
> 
> TZ='NZST-12NZDT,M9.5.0,M4.1.0/3' date -d@0 +'%Y-%m-%d %H:%M:%S %z (%Z)'
> 
> On a working system with GNU 'date', it should output this:
> 
> 1970-01-01 13:00:00 +1300 (NZDT)
> 
> If it outputs "1970-01-01 12:00:00 +1200 (NZST)" on Cygwin, it's a bug in Cygwin 
> not in Emacs per se. If so, perhaps we should just skip the test on Cygwin (you 
> might file a Cygwin bug report). If not, I'll have some other questions to ask.

I've found 2 issues with this test in the MinGW build on MS-Windows.
I would like to propose the following changes.  Paul, is it okay to
commit this?

diff --git a/test/src/editfns-tests.el b/test/src/editfns-tests.el
index 44595be..80af441 100644
--- a/test/src/editfns-tests.el
+++ b/test/src/editfns-tests.el
@@ -144,12 +144,16 @@ transpose-test-get-byte-positions
            (format-time-string "%Y-%m-%d %H:%M:%S %z" '(0 0 0 0) t)
            "1970-01-01 00:00:00 +0000"))
   (should (string-equal
-           (format-time-string "%Y-%m-%d %H:%M:%S %z (%Z)" '(0 0 0 0) "PST8")
-           "1969-12-31 16:00:00 -0800 (PST)"))
-  (should (string-equal
-           (format-time-string "%Y-%m-%d %H:%M:%S %z (%Z)" '(0 0 0 0)
-                               "NZST-12NZDT,M9.5.0,M4.1.0/3")
-           "1970-01-01 13:00:00 +1300 (NZDT)")))
+           ;; Use local date of Jan 2, 1970, as MS-Windows produces an empty
+           ;; numerical time-zone from %z for times before the epoch.
+           (format-time-string "%Y-%m-%d %H:%M:%S %z (%Z)" '(1 20864 0 0) "PST8")
+           "1970-01-01 16:00:00 -0800 (PST)"))
+  ;; MS-Windows doesn't support the full  Posix format of TZ values.
+  (or (eq system-type 'windows-nt)
+      (should (string-equal
+               (format-time-string "%Y-%m-%d %H:%M:%S %z (%Z)" '(0 0 0 0)
+                                   "NZST-12NZDT,M9.5.0,M4.1.0/3")
+               "1970-01-01 13:00:00 +1300 (NZDT)"))))
 
 ;;; This should not dump core.
 (ert-deftest format-time-string-with-outlandish-zone ()

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

On 05/01/2017 12:43 AM, Eli Zaretskii wrote:
> I've found 2 issues with this test in the MinGW build on MS-Windows. 

Yes, clearly MS-Windows is buggy in this area, but only time nerds like 
me care about this sort of thing so I installed the attached, which 
should stop testing the buggy timestamps in early 1970 (while avoiding 
portability problems with timestamps after mid-1972).

[-- Attachment #2: 0001-Don-t-stress-test-time-zones-near-the-Epoch.txt --]
[-- Type: text/plain, Size: 3376 bytes --]

From d9868ac3defdde84a9555e9f7698603f634ca7d8 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 1 May 2017 10:41:50 -0700
Subject: [PATCH] =?UTF-8?q?Don=E2=80=99t=20stress-test=20time=20zones=20ne?=
 =?UTF-8?q?ar=20the=20Epoch?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* test/src/editfns-tests.el (format-time-string-with-zone)
(format-time-string-with-outlandish-zone): Don’t format
timestamps near the Epoch, as this runs into bugs on MS-Windows,
and we don’t want to worry about those bugs.
---
 test/src/editfns-tests.el | 39 ++++++++++++++++++++++++++++-----------
 1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/test/src/editfns-tests.el b/test/src/editfns-tests.el
index 44595be..3fd3cc1 100644
--- a/test/src/editfns-tests.el
+++ b/test/src/editfns-tests.el
@@ -140,21 +140,38 @@ transpose-test-get-byte-positions
 ;;; Use only POSIX-compatible TZ values, since the tests should work
 ;;; even if tzdb is not in use.
 (ert-deftest format-time-string-with-zone ()
-  (should (string-equal
-           (format-time-string "%Y-%m-%d %H:%M:%S %z" '(0 0 0 0) t)
-           "1970-01-01 00:00:00 +0000"))
-  (should (string-equal
-           (format-time-string "%Y-%m-%d %H:%M:%S %z (%Z)" '(0 0 0 0) "PST8")
-           "1969-12-31 16:00:00 -0800 (PST)"))
-  (should (string-equal
-           (format-time-string "%Y-%m-%d %H:%M:%S %z (%Z)" '(0 0 0 0)
-                               "NZST-12NZDT,M9.5.0,M4.1.0/3")
-           "1970-01-01 13:00:00 +1300 (NZDT)")))
+  ;; Don’t use (0 0 0 0) as the test case, as there are too many bugs
+  ;; in MSVC (and presumably other) C libraries when formatting time
+  ;; stamps near the Epoch of 1970-01-01 00:00:00 UTC, and this test
+  ;; is for GNU Emacs, not for C runtimes.  Instead, look before you
+  ;; leap: "look" is the timestamp just before the first leap second
+  ;; on 1972-06-30 23:59:60 UTC, so it should format to the same
+  ;; string regardless of whether the underlying C library ignores
+  ;; leap seconds, while avoiding circa-1970 glitches.
+  (let ((look '(1202 22527 999999 999999)))
+    ;; UTC.
+    (should (string-equal
+             (format-time-string "%Y-%m-%d %H:%M:%S.%3N %z" look t)
+             "1972-06-30 23:59:59.999 +0000"))
+    ;; Time zone without DST in 1972.
+    (should (string-equal
+             (format-time-string "%Y-%m-%d %H:%M:%S.%3N %z (%Z)" look "NZST-12")
+             "1972-07-01 11:59:59.999 +1200 (NZST)"))
+    ;; United States DST in 1972.
+    (should (string-equal
+             (format-time-string "%Y-%m-%d %H:%M:%S.%3N %z (%Z)" look
+                                 "PST8PDT,M4.5.0,M10.5,0")
+             "1972-06-30 16:59:59.999 -0700 (PDT)"))
+    ;; New South Wales DST in 1971-2.
+    (should (string-equal
+             (format-time-string "%Y-%m-%d %H:%M:%S.%3N %z (%Z)" look
+                                 "AEST-10AEDT,M10.5.0,M2.5.0/3")
+             "1972-07-01 09:59:59.999 +1000 (AEST)"))))
 
 ;;; This should not dump core.
 (ert-deftest format-time-string-with-outlandish-zone ()
   (should (stringp
-           (format-time-string "%Y-%m-%d %H:%M:%S %z" '(0 0 0 0)
+           (format-time-string "%Y-%m-%d %H:%M:%S.%3N %z" nil
                                (concat (make-string 2048 ?X) "0")))))
 
 ;;; editfns-tests.el ends here
-- 
2.9.3

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Eli Zaretskii]

> Cc: kbrown@cornell.edu, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 1 May 2017 10:49:17 -0700
> 
> On 05/01/2017 12:43 AM, Eli Zaretskii wrote:
> > I've found 2 issues with this test in the MinGW build on MS-Windows. 
> 
> Yes, clearly MS-Windows is buggy in this area, but only time nerds like 
> me care about this sort of thing so I installed the attached, which 
> should stop testing the buggy timestamps in early 1970 (while avoiding 
> portability problems with timestamps after mid-1972).

Thanks.  This version still has problems in the MinGW build:

 . The Windows runtime supports only 3-letter TZ abbreviations, so
   things like NZST and AEST confuse it.  (It doesn't care about the
   letters, it just needs to be 3 of them.)

 . The Windows runtime doesn't support Posix DST transition rules in
   the TZ setting, it uses the "old USA rules" (see
   https://msdn.microsoft.com/en-us/library/90s5c885.aspx for the
   details), so "AEST-10AEDT,M10.5.0,M2.5.0/3" doesn't produce the
   correct result, even if AEST and AEDT are replaced with 3-letter
   zones.  So if we want to test that DST works, the rules must be
   compatible with the old US rules, i.e. between the 1st Sunday of
   April and the last Sunday of October.

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 232 bytes --]

On 05/01/2017 12:36 PM, Eli Zaretskii wrote:
> Thanks.  This version still has problems in the MinGW build:

Oh my, I wasn't aware that MinGW timezones were so limited. I installed 
the attached to try to fix the test accordingly.


[-- Attachment #2: 0001-Port-format-time-string-to-MS-Windows-better.patch --]
[-- Type: text/x-patch, Size: 2591 bytes --]

From bc921e840783f0e9cb985d02d6ea2138ecdc01c9 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 1 May 2017 16:02:31 -0700
Subject: [PATCH] Port format-time-string to MS-Windows better

* test/src/editfns-tests.el (format-time-string-with-zone):
Port test cases to MS-Windows.
---
 test/src/editfns-tests.el | 27 +++++++++++++++------------
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/test/src/editfns-tests.el b/test/src/editfns-tests.el
index 7c555d9..8019eb0 100644
--- a/test/src/editfns-tests.el
+++ b/test/src/editfns-tests.el
@@ -148,25 +148,28 @@ transpose-test-get-byte-positions
   ;; second on 1972-06-30 23:59:60 UTC, so it should format to the
   ;; same string regardless of whether the underlying C library
   ;; ignores leap seconds, while avoiding circa-1970 glitches.
-  (let ((look '(1202 22527 999999 999999)))
+  ;;
+  ;; Similarly, stick to the limited set of time zones that are
+  ;; supported by both POSIX and MS-Windows: exactly 3 ASCII letters
+  ;; in the abbreviation, and no DST.
+  (let ((look '(1202 22527 999999 999999))
+        (format "%Y-%m-%d %H:%M:%S.%3N %z (%Z)"))
     ;; UTC.
     (should (string-equal
              (format-time-string "%Y-%m-%d %H:%M:%S.%3N %z" look t)
              "1972-06-30 23:59:59.999 +0000"))
-    ;; Time zone without DST in 1972.
+    ;; "UTC0".
     (should (string-equal
-             (format-time-string "%Y-%m-%d %H:%M:%S.%3N %z (%Z)" look "NZST-12")
-             "1972-07-01 11:59:59.999 +1200 (NZST)"))
-    ;; United States DST in 1972.
+             (format-time-string format look "UTC0")
+             "1972-06-30 23:59:59.999 +0000 (UTC)"))
+    ;; Negative UTC offset, as a Lisp list.
     (should (string-equal
-             (format-time-string "%Y-%m-%d %H:%M:%S.%3N %z (%Z)" look
-                                 "PST8PDT,M4.5.0,M10.5.0")
-             "1972-06-30 16:59:59.999 -0700 (PDT)"))
-    ;; New South Wales DST in 1971-2.
+             (format-time-string format look '(-28800 "PST"))
+             "1972-06-30 15:59:59.999 -0800 (PST)"))
+    ;; Positive UTC offset that is not an hour multiple, as a string.
     (should (string-equal
-             (format-time-string "%Y-%m-%d %H:%M:%S.%3N %z (%Z)" look
-                                 "AEST-10AEDT,M10.5.0,M2.5.0/3")
-             "1972-07-01 09:59:59.999 +1000 (AEST)"))))
+             (format-time-string format look "IST-5:30")
+             "1972-07-01 05:29:59.999 +0530 (IST)"))))
 
 ;;; This should not dump core.
 (ert-deftest format-time-string-with-outlandish-zone ()
-- 
2.9.3

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Eli Zaretskii]

> Cc: kbrown@cornell.edu, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 1 May 2017 16:05:21 -0700
> 
> On 05/01/2017 12:36 PM, Eli Zaretskii wrote:
> > Thanks.  This version still has problems in the MinGW build:
> 
> Oh my, I wasn't aware that MinGW timezones were so limited.

More accurately, the support for the timezone specs via the TZ
environment variable is very limited.  The native Windows way of
specifying timezones is as rich as that on Posix systems, but it uses
programmatic APIs, not environment variables or databases stored on
files.

> I installed the attached to try to fix the test accordingly.

Thanks, all the tests now pass.

However, the utimens.c file you've brought from Gnulib has 2 problems:

  . it defines WIN32_LEAN_AND_MEAN unconditionally, which conflicts
    with our own definition in nt/inc/ms-w32.h, which is processed
    earlier;

  . it includes msvc-nothrow.h, which is absent in the repository, it
    should have been imported from Gnulib together with utimens.c

I fixed the first of these temporarily, in a way that at least GCC
lets utimens.c compile, but I think in general utimens.c should do

  #ifndef WIN32_LEAN_AND_MEAN
  # define WIN32_LEAN_AND_MEAN
  #endif

to avoid possible clashes with definitions elsewhere in the sources.

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

Eli Zaretskii wrote:

> the utimens.c file you've brought from Gnulib has 2 problems:
>
>   . it defines WIN32_LEAN_AND_MEAN unconditionally, which conflicts
>     with our own definition in nt/inc/ms-w32.h, which is processed
>     earlier;
>
>   . it includes msvc-nothrow.h, which is absent in the repository, it
>     should have been imported from Gnulib together with utimens.c
>
> I fixed the first of these temporarily, in a way that at least GCC
> lets utimens.c compile, but I think in general utimens.c should do
>
>   #ifndef WIN32_LEAN_AND_MEAN
>   # define WIN32_LEAN_AND_MEAN
>   #endif
>
> to avoid possible clashes with definitions elsewhere in the sources.

I'd like Bruno's opinion on the macro clash, and on the attached patch for the 
msvc-nothrow.h issue, a patch that I installed into Gnulib and into Emacs master 
to try to get the Emacs master build working again.

For quite some time Emacs has avoided Gnulib's msvc-nothrow and msvc-inval 
modules, the reason for which I do not understand (and don't particularly want 
to :-). It's trivial to add the msvc-nothrow and msvc-inval machinery to the 
Emacs source code, if this is necessary now for some reason: simply remove them 
from the AVOIDED_MODULES list in admin/merge-gnulib and then run 
admin/merge-gnulib. I don't know whether this would break other parts of the 
build on MS-Windows, though.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-utimens-port-to-Emacs-MS-Windows.patch --]
[-- Type: text/x-diff; name="0001-utimens-port-to-Emacs-MS-Windows.patch", Size: 2140 bytes --]

From fb26fc4b4ad7db1d12933aefc3d213c6f217092c Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 2 May 2017 00:40:41 -0700
Subject: [PATCH] utimens: port to Emacs + MS-Windows

Skip the new MS-Windows-specific code if Emacs.
* lib/utimens.c [EMACS_CONFIGUATION]:
Avoid new MS-Windows-specific code.
(USE_SETFILETIME): New macro.
(fdutimens): Use it.
---
 ChangeLog     |  9 +++++++++
 lib/utimens.c | 10 ++++++++--
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index ad44003..8c91b23 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2017-05-02  Paul Eggert  <eggert@cs.ucla.edu>
+
+	utimens: port to Emacs + MS-Windows
+	Skip the new MS-Windows-specific code if Emacs.
+	* lib/utimens.c [EMACS_CONFIGUATION]:
+	Avoid new MS-Windows-specific code.
+	(USE_SETFILETIME): New macro.
+	(fdutimens): Use it.
+
 2017-05-01  Paul Eggert  <eggert@cs.ucla.edu>
 
 	tzset: update doc for TZ problems on MS-Windows
diff --git a/lib/utimens.c b/lib/utimens.c
index 0b3b8e2..5f3a846 100644
--- a/lib/utimens.c
+++ b/lib/utimens.c
@@ -35,7 +35,13 @@
 #include "stat-time.h"
 #include "timespec.h"
 
-#if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
+/* On native Windows, use SetFileTime; but avoid this when compiling
+   GNU Emacs, which arranges for this in some other way and which
+   defines WIN32_LEAN_AND_MEAN itself.  */
+
+#if ((defined _WIN32 || defined __WIN32__) \
+     && ! defined __CYGWIN__ && ! defined EMACS_CONFIGURATION)
+# define USE_SETFILETIME
 # define WIN32_LEAN_AND_MEAN
 # include <windows.h>
 # include "msvc-nothrow.h"
@@ -277,7 +283,7 @@ fdutimens (int fd, char const *file, struct timespec const timespec[2])
   lutimensat_works_really = -1;
 #endif /* HAVE_UTIMENSAT || HAVE_FUTIMENS */
 
-#if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
+#ifdef USE_SETFILETIME
   /* On native Windows, use SetFileTime(). See
      <https://msdn.microsoft.com/en-us/library/ms724933.aspx>
      <https://msdn.microsoft.com/en-us/library/ms724284.aspx>  */
-- 
2.7.4

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Eli Zaretskii]

> Cc: kbrown@cornell.edu, emacs-devel@gnu.org, Bruno Haible <bruno@clisp.org>,
>  Gnulib bugs <bug-gnulib@gnu.org>
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 2 May 2017 00:52:03 -0700
> 
> > the utimens.c file you've brought from Gnulib has 2 problems:
> >
> >   . it defines WIN32_LEAN_AND_MEAN unconditionally, which conflicts
> >     with our own definition in nt/inc/ms-w32.h, which is processed
> >     earlier;
> >
> >   . it includes msvc-nothrow.h, which is absent in the repository, it
> >     should have been imported from Gnulib together with utimens.c
> >
> > I fixed the first of these temporarily, in a way that at least GCC
> > lets utimens.c compile, but I think in general utimens.c should do
> >
> >   #ifndef WIN32_LEAN_AND_MEAN
> >   # define WIN32_LEAN_AND_MEAN
> >   #endif
> >
> > to avoid possible clashes with definitions elsewhere in the sources.
> 
> I'd like Bruno's opinion on the macro clash, and on the attached patch for the 
> msvc-nothrow.h issue, a patch that I installed into Gnulib and into Emacs master 
> to try to get the Emacs master build working again.

Thanks.

> -#if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
> +/* On native Windows, use SetFileTime; but avoid this when compiling
> +   GNU Emacs, which arranges for this in some other way and which
> +   defines WIN32_LEAN_AND_MEAN itself.  */

That "other way" is the implementation of fdutimens in Emacs's w32.c.
Perhaps Bruno could look at that implementation and comment on its
merits and demerits vs the Gnulib implementation, and we could then
decide whether to start using the Gnulib implementation, augmenting
ours, or something else.

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Bruno Haible]

Paul Eggert wrote:
> I'd like Bruno's opinion on the macro clash

The common idiom is "#define WINDOWS_LEAN_AND_MEAN". This can be seen by comparing
the number of hits of two web searches:
  https://www.google.de/search?q=%22define+windows_lean_and_mean%22
  https://www.google.de/search?q=%22define+windows_lean_and_mean+1%22

> and on the attached patch for the 
> msvc-nothrow.h issue, a patch that I installed into Gnulib and into Emacs master 

The patch is fine with me: it has no drawbacks for other packages.

However, it would be good to know what qualms you have with the msvc-nothrow
module. Should Emacs be built with mingw, not MSVC? Is an EBADF situation never
going to occur in Emacs anyway? Are the portability efforts for mingw and MSVC
in Gnulib useless for Emacs, because on native Windows Emacs uses its own w32.c
instead anyway? Does Emacs have other requirements I don't know about?

Eli Zaretskii wrote:
> That "other way" is the implementation of fdutimens in Emacs's w32.c.
> Perhaps Bruno could look at that implementation and comment on its
> merits and demerits vs the Gnulib implementation

1) The Emacs w32.c ports to Windows98 as well, whereas Gnulib currently assumes
Windows XP at least (and will soon move to Windows 7, I guess - namely when
no one has a test machine with Windows XP any more). Merit or demerit? Opinion?

2) The Emacs w32.c has an option to use the "W" suffixed Windows APIs by default.
Clearly a merit, because it allows to use file names that are not contained in
the "ANSI codepage". Nowadays users can use (type, display, manipulate) such
file names in the cmd.exe windows; any program which is not on par with this
ability is deficient.
Gnulib still uses the "A" suffixed Windows APIs; clearly a demerit.

3) The Emacs w32.c fdutimens function handles only 1 second resolution; the
Gnulib fdutimens supports sub-second resolution.

4) Different errno mapping:

Filename                            GetLastError()           errno in Emacs   errno in Gnulib

'\\server'                          ERROR_BAD_PATHNAME       EINVAL           ENOENT
'\\server\nonexistentshare\'        ERROR_BAD_NET_NAME       EINVAL           ENOENT
 ?                                  ERROR_INVALID_DRIVE      ENOENT           EINVAL
 ?                                  ERROR_BAD_NETPATH        ENOENT           EINVAL
 ?                                  ERROR_DEV_NOT_EXIST      ENOENT           EINVAL
'C:\System Volume Information\foo'  ERROR_ACCESS_DENIED      EACCES           EACCESS or EPERM (*)
'C:\pagefile.sys'                   ERROR_SHARING_VIOLATION  EACCES           EACCESS or EPERM (*)

(*) According to POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/functions/utime.html

Can you tell me how to provoke a ERROR_INVALID_DRIVE, ERROR_BAD_NETPATH, or
ERROR_DEV_NOT_EXIST error code?

5) Anything else?

Bruno

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Paul Eggert]

On 05/02/2017 02:55 PM, Bruno Haible wrote:
> it would be good to know what qualms you have with the msvc-nothrow
> module. Should Emacs be built with mingw, not MSVC? Is an EBADF situation never
> going to occur in Emacs anyway? Are the portability efforts for mingw and MSVC
> in Gnulib useless for Emacs, because on native Windows Emacs uses its own w32.c
> instead anyway? Does Emacs have other requirements I don't know about?

I know little about MS-Windows. Emacs has gotten along without 
msvc-nothrow and msvc-inval for quite some time and so may not need 
them.  Adding them to Emacs may break MS-Windows builds in subtle ways 
that I am not qualified to judge. So, being cautious, I omitted them.

There was a similar issue with the recent Gnulib changes for 
daylight-saving time in MS-Windows, where I omitted the relevant modules 
from Emacs because Emacs has been running for years without these DST 
fixes and I worried that adding the new Gnulib modules would break 
and/or complicate the Emacs build unnecessarily.

It should be easy enough for someone with MS-Windows expertise to 
experiment with the new Gnulib functionality in Emacs: in the Emacs 
master branch, edit admin/merge-gnulib's AVOIDED_MODULES variable so 
that it no longer lists the modules you want to use. Then run 
admin/merge-gnulib and build the result on MS-Windows.

> 1) The Emacs w32.c ports to Windows98 as well, whereas Gnulib currently assumes
> Windows XP at least (and will soon move to Windows 7, I guess - namely when
> no one has a test machine with Windows XP any more). Merit or demerit? Opinion?

In the past Eli has argued for supporting ancient MS-Windows and MS-DOS 
versions. I don't know whether he still cares. (By "ancient" I mean that 
Microsoft itself no longer supports them.)

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Eli Zaretskii]

> Cc: kbrown@cornell.edu, emacs-devel@gnu.org, bug-gnulib@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Tue, 2 May 2017 15:35:03 -0700
> 
> > 1) The Emacs w32.c ports to Windows98 as well, whereas Gnulib currently assumes
> > Windows XP at least (and will soon move to Windows 7, I guess - namely when
> > no one has a test machine with Windows XP any more). Merit or demerit? Opinion?
> 
> In the past Eli has argued for supporting ancient MS-Windows and MS-DOS 
> versions. I don't know whether he still cares. (By "ancient" I mean that 
> Microsoft itself no longer supports them.)

We still try to support Windows 9X, but MS-DOS is not relevant to this
discussion, as it does use the Gnulib implementation of fdutimens.

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Cc: kbrown@cornell.edu, emacs-devel@gnu.org, bug-gnulib@gnu.org
> Date: Tue, 02 May 2017 23:55:50 +0200
> 
> The patch is fine with me: it has no drawbacks for other packages.

Thanks.

> However, it would be good to know what qualms you have with the msvc-nothrow
> module. Should Emacs be built with mingw, not MSVC?

Emacs dropped MSVC support a few years ago.  Only MinGW, with its 2
flavors, is currently supported, in addition to Cygwin.  Emacs might
still build with MSVC, but I don't think anyone tried in a long while,
and if they do, they will be in for a ride, because we require the
MSYS tools to run the configure script and the Makefiles.

> Is an EBADF situation never going to occur in Emacs anyway?

It can occur, but AFAIK it cannot cause an exception, since the only
supported runtime is msvcrt.dll.

> Are the portability efforts for mingw and MSVC
> in Gnulib useless for Emacs, because on native Windows Emacs uses its own w32.c
> instead anyway?

Many features available from Gnulib are indeed independently
implemented in w32.c and other Windows-specific files in Emacs.  The
reasons vary -- some are of historical nature, others because the
Emacs implementations are "better" in some sense.  The support for
non-ASCII file names outside of the current system codepage is a good
example of the latter.

> Does Emacs have other requirements I don't know about?

Some.  For example, Emacs cannot use the C runtime functions that
manipulate non-ASCII characters, because those are limited to the BMP
on Windows, and don't support UTF-8.

> Eli Zaretskii wrote:
> > That "other way" is the implementation of fdutimens in Emacs's w32.c.
> > Perhaps Bruno could look at that implementation and comment on its
> > merits and demerits vs the Gnulib implementation
> 
> 1) The Emacs w32.c ports to Windows98 as well, whereas Gnulib currently assumes
> Windows XP at least (and will soon move to Windows 7, I guess - namely when
> no one has a test machine with Windows XP any more). Merit or demerit? Opinion?

Emacs still tries to support Windows 9X and the NT family members
older than XP, yes.  But AFAICT, the APIs used in the Gnulib
implementation of fdutimens are all supported on Windows 9X.

> 2) The Emacs w32.c has an option to use the "W" suffixed Windows APIs by default.
> Clearly a merit, because it allows to use file names that are not contained in
> the "ANSI codepage". Nowadays users can use (type, display, manipulate) such
> file names in the cmd.exe windows; any program which is not on par with this
> ability is deficient.

In a GUI session, Emacs supports all the Unicode characters, so
limiting file names to the current codepage makes even less sense than
for console programs running in the cmd window.

> 3) The Emacs w32.c fdutimens function handles only 1 second resolution; the
> Gnulib fdutimens supports sub-second resolution.

I guess we should plan on reimplementing the Emacs version using the
more flexible Win32 APIs, to support sub-second resolution.

> Can you tell me how to provoke a ERROR_INVALID_DRIVE, ERROR_BAD_NETPATH, or
> ERROR_DEV_NOT_EXIST error code?

I don't remember.  It's entirely possible that I just looked at the
textual representation of these errors and matched the errno values
without actually creating the situation.

Thanks for the detailed analysis.

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Davis Herring]

On 05/02/2017 03:55 PM, Bruno Haible wrote:
> Filename                            GetLastError()           errno in Emacs   errno in Gnulib
>
> '\\server'                          ERROR_BAD_PATHNAME       EINVAL           ENOENT
> '\\server\nonexistentshare\'        ERROR_BAD_NET_NAME       EINVAL           ENOENT
>  ?                                  ERROR_INVALID_DRIVE      ENOENT           EINVAL
>  ?                                  ERROR_BAD_NETPATH        ENOENT           EINVAL
>  ?                                  ERROR_DEV_NOT_EXIST      ENOENT           EINVAL
> 'C:\System Volume Information\foo'  ERROR_ACCESS_DENIED      EACCES           EACCESS or EPERM (*)
> 'C:\pagefile.sys'                   ERROR_SHARING_VIOLATION  EACCES           EACCESS or EPERM (*)
>
> (*) According to POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/functions/utime.html
>
> Can you tell me how to provoke a ERROR_INVALID_DRIVE, ERROR_BAD_NETPATH, or
> ERROR_DEV_NOT_EXIST error code?

Billy O'Neal (copied) at Microsoft might be able to help; he's been 
doing similar error-code mapping for their filesystems (for C++17).

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 
shipping.

RE: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Billy O'Neal (VC LIBS)]

[-- Attachment #1: Type: text/plain, Size: 3988 bytes --]

I’m not an expert at all in this area. I did run a few queries against Win sources though.

I think ERROR_INVALID_DRIVE is dead. The only place I found it mentioned was in the CRT trying to translate it to ENOENT. There was a comment from 1989 there, it may have meant something in the DOS / Win9x days.

ERROR_BAD_NETPATH seems to happen when the path looks okay but DNS fails on the input:

//
// MessageId: ERROR_BAD_NETPATH
//
// MessageText:
//
// The network path was not found.
//
#define ERROR_BAD_NETPATH                53L

C:\Users\bion\Desktop>type test_error.cpp
#include <stdio.h>
#include <system_error>
#include <Windows.h>

int wmain(int argc, wchar_t *argv[]) {
    if (argc != 2) {
        puts("usage: test_error.exe path");
        return -1;
    }
    HANDLE hFile = CreateFileW(
        argv[1],
        FILE_READ_ATTRIBUTES,
        FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
        0,
        OPEN_EXISTING,
        FILE_ATTRIBUTE_NORMAL,
        nullptr);

    if (hFile != INVALID_HANDLE_VALUE) {
        puts("didn't get expected error");
        CloseHandle(hFile);
        return -1;
    }

    DWORD lastError = GetLastError();
    printf("GetLastError() == %lu == 0x%08lX: %s", lastError, lastError,
        std::system_category().message(lastError).c_str());
    return 0;
}

C:\Users\bion\Desktop>cl /nologo /EHsc /W4 /WX .\test_error.cpp
test_error.cpp

C:\Users\bion\Desktop>.\test_error.exe \\notaserver.example.com\foo\bar\baz
GetLastError() == 53 == 0x00000035: The network path was not found.

C:\Users\bion\Desktop>

I don’t think ERROR_DEV_NOT_EXIST can be triggered from a file path. I saw it only in places where mount points were being processed. (e.g. you tried to mount this device but that device doesn’t exist) But I’m not positive.

Hope that helps,

Billy3

From: Davis Herring<mailto:herring@lanl.gov>
Sent: Wednesday, May 3, 2017 12:36 PM
To: Bruno Haible<mailto:bruno@clisp.org>; Eli Zaretskii<mailto:eliz@gnu.org>; Paul Eggert<mailto:eggert@cs.ucla.edu>
Cc: bug-gnulib@gnu.org<mailto:bug-gnulib@gnu.org>; kbrown@cornell.edu<mailto:kbrown@cornell.edu>; emacs-devel@gnu.org<mailto:emacs-devel@gnu.org>; Billy O'Neal (VC LIBS)<mailto:bion@microsoft.com>
Subject: Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

On 05/02/2017 03:55 PM, Bruno Haible wrote:
> Filename                            GetLastError()           errno in Emacs   errno in Gnulib
>
> '\\server'                          ERROR_BAD_PATHNAME       EINVAL           ENOENT
> '\\server\nonexistentshare\<file://server/nonexistentshare/>'        ERROR_BAD_NET_NAME       EINVAL           ENOENT
>  ?                                  ERROR_INVALID_DRIVE      ENOENT           EINVAL
>  ?                                  ERROR_BAD_NETPATH        ENOENT           EINVAL
>  ?                                  ERROR_DEV_NOT_EXIST      ENOENT           EINVAL
> 'C:\System Volume Information\foo'  ERROR_ACCESS_DENIED      EACCES           EACCESS or EPERM (*)
> 'C:\pagefile.sys'                   ERROR_SHARING_VIOLATION  EACCES           EACCESS or EPERM (*)
>
> (*) According to POSIX: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F9699919799%2Ffunctions%2Futime.html&data=02%7C01%7Cbion%40microsoft.com%7C60b0e84189a14768804d08d4925ba869%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636294369742721148&sdata=s77csbmK5uw8tn7mB6JvCYJ%2BlMQFB9FDtCrgi01z5EE%3D&reserved=0
>
> Can you tell me how to provoke a ERROR_INVALID_DRIVE, ERROR_BAD_NETPATH, or
> ERROR_DEV_NOT_EXIST error code?

Billy O'Neal (copied) at Microsoft might be able to help; he's been
doing similar error-code mapping for their filesystems (for C++17).

Davis

--
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.


[-- Attachment #2: Type: text/html, Size: 14866 bytes --]

Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Eli Zaretskii]

> From: "Billy O'Neal (VC LIBS)" <bion@microsoft.com>
> CC: "bug-gnulib@gnu.org" <bug-gnulib@gnu.org>, "kbrown@cornell.edu"
> 	<kbrown@cornell.edu>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Wed, 3 May 2017 21:12:33 +0000
> 
> I’m not an expert at all in this area. I did run a few queries against Win sources though.

Thanks for your input, much appreciated.