* MinGW-related patches that were reported in 2014 but not applied @ 2016-07-15 19:04 Eli Zaretskii 2016-07-16 8:33 ` Andy Wingo 2016-07-17 6:04 ` Andy Wingo 0 siblings, 2 replies; 13+ messages in thread From: Eli Zaretskii @ 2016-07-15 19:04 UTC (permalink / raw) To: Andy Wingo; +Cc: guile-devel I built Guile 2.0.12 today with MinGW, and to my chagrin found that some of the patches I sent long ago are still not in the repository. Below please find the list of those patches. The stime.c patch in this message was not applied, although it causes failures in time.test (explained in the message): https://lists.gnu.org/archive/html/guile-devel/2014-06/msg00012.html The issues with dirname and basename, for which I posted a patch here: https://lists.gnu.org/archive/html/guile-devel/2014-07/msg00012.html were subsequently discussed, but the code was not changed, AFAICT. This patch is needed, because without it Guile will write corrupted *.go files: https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00052.html Can these please be applied? TIA ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MinGW-related patches that were reported in 2014 but not applied 2016-07-15 19:04 MinGW-related patches that were reported in 2014 but not applied Eli Zaretskii @ 2016-07-16 8:33 ` Andy Wingo 2016-07-16 11:24 ` Eli Zaretskii 2016-07-17 6:04 ` Andy Wingo 1 sibling, 1 reply; 13+ messages in thread From: Andy Wingo @ 2016-07-16 8:33 UTC (permalink / raw) To: Eli Zaretskii; +Cc: guile-devel Hi, On Fri 15 Jul 2016 21:04, Eli Zaretskii <eliz@gnu.org> writes: > I built Guile 2.0.12 today with MinGW, and to my chagrin found that > some of the patches I sent long ago are still not in the repository. > > Below please find the list of those patches. > > The stime.c patch in this message was not applied, although it causes > failures in time.test (explained in the message): > > https://lists.gnu.org/archive/html/guile-devel/2014-06/msg00012.html > > The issues with dirname and basename, for which I posted a patch here: > > https://lists.gnu.org/archive/html/guile-devel/2014-07/msg00012.html > > were subsequently discussed, but the code was not changed, AFAICT. > > This patch is needed, because without it Guile will write corrupted > *.go files: > > https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00052.html > > Can these please be applied? Sure let's work on it. Would you mind submitting these again, making sure they apply cleanly to stable-2.0? Thanks, Andy ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MinGW-related patches that were reported in 2014 but not applied 2016-07-16 8:33 ` Andy Wingo @ 2016-07-16 11:24 ` Eli Zaretskii 2016-07-16 13:39 ` Andy Wingo 2016-07-23 12:15 ` Andy Wingo 0 siblings, 2 replies; 13+ messages in thread From: Eli Zaretskii @ 2016-07-16 11:24 UTC (permalink / raw) To: Andy Wingo; +Cc: guile-devel [-- Attachment #1: Type: text/plain, Size: 312 bytes --] > From: Andy Wingo <wingo@pobox.com> > Cc: guile-devel@gnu.org > Date: Sat, 16 Jul 2016 10:33:56 +0200 > > > Can these please be applied? > > Sure let's work on it. Would you mind submitting these again, making > sure they apply cleanly to stable-2.0? 3 patches against the current stable-2.0 are attached. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Open-temporary-files-in-binary-mode-on-MS-Windows.patch --] [-- Type: text/x-patch, Size: 1143 bytes --] From 8a1e4631fc2dddf5ca63039b4a77ae0d33d3cb90 Mon Sep 17 00:00:00 2001 From: Eli Zaretskii <eliz@gnu.org> Date: Sat, 16 Jul 2016 14:17:25 +0300 Subject: [PATCH] Open temporary files in binary mode on MS-Windows * libguile/filesys.c (scm_mkstemp) [__MINGW32__]: Make sure the temporary file is open in binary mode. --- libguile/filesys.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/libguile/filesys.c b/libguile/filesys.c index 48232e8..c47c2f4 100644 --- a/libguile/filesys.c +++ b/libguile/filesys.c @@ -1472,6 +1472,14 @@ SCM_DEFINE (scm_mkstemp, "mkstemp!", 1, 0, 0, SCM_SYSCALL (rv = mkstemp (c_tmpl)); if (rv == -1) SCM_SYSERROR; +#ifdef __MINGW32__ + /* Files created by this function are used for *.go files, so make + sure they use binary I/O, or else the produced *.go files will be + corrupted by end-of-line conversion and ^Z "software EOF" + misfeature. Gnulib's 'mkstemp' uses the default text mode to + open the file . */ + _setmode (rv, _O_BINARY); +#endif scm_substring_move_x (scm_from_locale_string (c_tmpl), SCM_INUM0, scm_string_length (tmpl), -- 2.9.0.windows.1 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #3: 0001-Fix-dirname-and-basename-on-MS-Windows.patch --] [-- Type: text/x-patch, Size: 5200 bytes --] From f598db99c0da4aefce0b393f52a4da8f0c4c055e Mon Sep 17 00:00:00 2001 From: Eli Zaretskii <eliz@gnu.org> Date: Sat, 16 Jul 2016 14:20:23 +0300 Subject: [PATCH] Fix 'dirname' and 'basename' on MS-Windows * libguile/filesys.c (is_drive_letter): New helper function. (scm_dirname, scm_basename): Use it. Don't assume the leading slash is always at the beginning of the file name. Support UNC file names on MS-Windows. --- libguile/filesys.c | 87 +++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 76 insertions(+), 11 deletions(-) diff --git a/libguile/filesys.c b/libguile/filesys.c index c47c2f4..55df768 100644 --- a/libguile/filesys.c +++ b/libguile/filesys.c @@ -449,6 +449,18 @@ is_file_name_separator (SCM c) return 0; } +static int +is_drive_letter (SCM c) +{ +#ifdef __MINGW32__ + if (SCM_CHAR (c) >= 'a' && SCM_CHAR (c) <= 'z') + return 1; + else if (SCM_CHAR (c) >= 'A' && SCM_CHAR (c) <= 'Z') + return 1; +#endif + return 0; +} + SCM_DEFINE (scm_stat, "stat", 1, 1, 0, (SCM object, SCM exception_on_error), "Return an object containing various information about the file\n" @@ -1522,24 +1534,60 @@ SCM_DEFINE (scm_dirname, "dirname", 1, 0, 0, { long int i; unsigned long int len; + /* Length of prefix before the top-level slash. Always zero on + Posix hosts, but may be non-zero on Windows. */ + long prefix_len = 0; + int is_unc = 0; + unsigned long unc_end = 0; SCM_VALIDATE_STRING (1, filename); len = scm_i_string_length (filename); + if (len >= 2 + && is_drive_letter (scm_c_string_ref (filename, 0)) + && scm_is_eq (scm_c_string_ref (filename, 1), SCM_MAKE_CHAR (':'))) + { + prefix_len = 1; + if (len > 2 && is_file_name_separator (scm_c_string_ref (filename, 2))) + prefix_len++; + } +#ifdef __MINGW32__ + if (len > 1 + && is_file_name_separator (scm_c_string_ref (filename, 0)) + && is_file_name_separator (scm_c_string_ref (filename, 1))) + { + is_unc = 1; + prefix_len = 1; + } +#endif i = len - 1; - while (i >= 0 && is_file_name_separator (scm_c_string_ref (filename, i))) + while (i >= prefix_len + && is_file_name_separator (scm_c_string_ref (filename, i))) --i; - while (i >= 0 && !is_file_name_separator (scm_c_string_ref (filename, i))) + if (is_unc) + unc_end = i + 1; + while (i >= prefix_len + && !is_file_name_separator (scm_c_string_ref (filename, i))) --i; - while (i >= 0 && is_file_name_separator (scm_c_string_ref (filename, i))) + while (i >= prefix_len + && is_file_name_separator (scm_c_string_ref (filename, i))) --i; - if (i < 0) + if (i < prefix_len) { - if (len > 0 && is_file_name_separator (scm_c_string_ref (filename, 0))) - return scm_c_substring (filename, 0, 1); + if (is_unc) + return scm_c_substring (filename, 0, unc_end); + else if (len > prefix_len + && is_file_name_separator (scm_c_string_ref (filename, prefix_len))) + return scm_c_substring (filename, 0, prefix_len + 1); +#ifdef __MINGW32__ + else if (len > prefix_len + && scm_is_eq (scm_c_string_ref (filename, 1), + SCM_MAKE_CHAR (':'))) + return scm_c_substring (filename, 0, prefix_len + 1); +#endif else return scm_dot_string; } @@ -1557,6 +1605,9 @@ SCM_DEFINE (scm_basename, "basename", 1, 1, 0, #define FUNC_NAME s_scm_basename { int i, j, len, end; + /* Length of prefix before the top-level slash. Always zero on + Posix hosts, but may be non-zero on Windows. */ + long prefix_len = 0; SCM_VALIDATE_STRING (1, filename); len = scm_i_string_length (filename); @@ -1568,11 +1619,17 @@ SCM_DEFINE (scm_basename, "basename", 1, 1, 0, SCM_VALIDATE_STRING (2, suffix); j = scm_i_string_length (suffix) - 1; } + if (len >= 2 + && is_drive_letter (scm_c_string_ref (filename, 0)) + && scm_is_eq (scm_c_string_ref (filename, 1), SCM_MAKE_CHAR (':'))) + prefix_len = 2; + i = len - 1; - while (i >= 0 && is_file_name_separator (scm_c_string_ref (filename, i))) + while (i >= prefix_len + && is_file_name_separator (scm_c_string_ref (filename, i))) --i; end = i; - while (i >= 0 && j >= 0 + while (i >= prefix_len && j >= 0 && (scm_i_string_ref (filename, i) == scm_i_string_ref (suffix, j))) { @@ -1581,12 +1638,20 @@ SCM_DEFINE (scm_basename, "basename", 1, 1, 0, } if (j == -1) end = i; - while (i >= 0 && !is_file_name_separator (scm_c_string_ref (filename, i))) + while (i >= prefix_len + && !is_file_name_separator (scm_c_string_ref (filename, i))) --i; if (i == end) { - if (len > 0 && is_file_name_separator (scm_c_string_ref (filename, 0))) - return scm_c_substring (filename, 0, 1); + if (len > prefix_len + && is_file_name_separator (scm_c_string_ref (filename, prefix_len))) + return scm_c_substring (filename, 0, prefix_len + 1); +#ifdef __MINGW32__ + else if (len > prefix_len + && scm_is_eq (scm_c_string_ref (filename, 1), + SCM_MAKE_CHAR (':'))) + return scm_c_substring (filename, 0, prefix_len + 1); +#endif else return scm_dot_string; } -- 2.9.0.windows.1 [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #4: 0001-Fix-strftime-for-MS-Windows.patch --] [-- Type: text/x-patch, Size: 1534 bytes --] From f55f1e8de40b38cc745a930bf5a374c73d3c67ce Mon Sep 17 00:00:00 2001 From: Eli Zaretskii <eliz@gnu.org> Date: Sat, 16 Jul 2016 14:22:06 +0300 Subject: [PATCH] Fix 'strftime' for MS-Windows * libguile/stime.c (scm_strftime) [__MINGW32__]: Don't use the trick of appending "0" to the time-zone string, Windows runtime doesn't support that. --- libguile/stime.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/libguile/stime.c b/libguile/stime.c index 7e6f303..745b50a 100644 --- a/libguile/stime.c +++ b/libguile/stime.c @@ -678,6 +678,10 @@ SCM_DEFINE (scm_strftime, "strftime", 2, 0, 0, tbuf = scm_malloc (size); { +#ifndef __MINGW32__ + /* Don't do this for MinGW: it only supports fixed-format + TTTnnnDDD TZ specifications, and gets confused if a zero is + appended. */ #if !defined (HAVE_TM_ZONE) /* it seems the only way to tell non-GNU versions of strftime what zone to use (for the %Z format) is to set TZ in the @@ -702,6 +706,7 @@ SCM_DEFINE (scm_strftime, "strftime", 2, 0, 0, oldenv = setzone (zone, SCM_ARG2, FUNC_NAME); } #endif +#endif #ifdef LOCALTIME_CACHE tzset (); @@ -716,6 +721,7 @@ SCM_DEFINE (scm_strftime, "strftime", 2, 0, 0, tbuf = scm_malloc (size); } +#ifndef __MINGW32__ #if !defined (HAVE_TM_ZONE) if (have_zone) { @@ -723,6 +729,7 @@ SCM_DEFINE (scm_strftime, "strftime", 2, 0, 0, SCM_CRITICAL_SECTION_END; } #endif +#endif } result = scm_from_utf8_string (tbuf + 1); -- 2.9.0.windows.1 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: MinGW-related patches that were reported in 2014 but not applied 2016-07-16 11:24 ` Eli Zaretskii @ 2016-07-16 13:39 ` Andy Wingo 2016-07-16 15:37 ` Eli Zaretskii 2016-07-23 12:15 ` Andy Wingo 1 sibling, 1 reply; 13+ messages in thread From: Andy Wingo @ 2016-07-16 13:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: guile-devel On Sat 16 Jul 2016 13:24, Eli Zaretskii <eliz@gnu.org> writes: > diff --git a/libguile/filesys.c b/libguile/filesys.c > index 48232e8..c47c2f4 100644 > --- a/libguile/filesys.c > +++ b/libguile/filesys.c > @@ -1472,6 +1472,14 @@ SCM_DEFINE (scm_mkstemp, "mkstemp!", 1, 0, 0, > SCM_SYSCALL (rv = mkstemp (c_tmpl)); > if (rv == -1) > SCM_SYSERROR; > +#ifdef __MINGW32__ > + /* Files created by this function are used for *.go files, so make > + sure they use binary I/O, or else the produced *.go files will be > + corrupted by end-of-line conversion and ^Z "software EOF" > + misfeature. Gnulib's 'mkstemp' uses the default text mode to > + open the file . */ > + _setmode (rv, _O_BINARY); > +#endif This function is used for other purposes as well. I think the right thing here is to use the mkostemp gnulib module instead and pass O_BINARY in the flags. I have made this change in git; please let me know if it causes problems for you. Andy ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MinGW-related patches that were reported in 2014 but not applied 2016-07-16 13:39 ` Andy Wingo @ 2016-07-16 15:37 ` Eli Zaretskii 2016-07-23 9:58 ` Andy Wingo 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2016-07-16 15:37 UTC (permalink / raw) To: Andy Wingo; +Cc: guile-devel > From: Andy Wingo <wingo@pobox.com> > Cc: guile-devel@gnu.org > Date: Sat, 16 Jul 2016 15:39:23 +0200 > > I think the right thing here is to use the mkostemp gnulib module > instead and pass O_BINARY in the flags. I have made this change in > git; please let me know if it causes problems for you. I'm sure it will DTRT, but it's hard for me to test such changes out of Git. Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MinGW-related patches that were reported in 2014 but not applied 2016-07-16 15:37 ` Eli Zaretskii @ 2016-07-23 9:58 ` Andy Wingo 0 siblings, 0 replies; 13+ messages in thread From: Andy Wingo @ 2016-07-23 9:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: guile-devel On Sat 16 Jul 2016 17:37, Eli Zaretskii <eliz@gnu.org> writes: >> From: Andy Wingo <wingo@pobox.com> >> Cc: guile-devel@gnu.org >> Date: Sat, 16 Jul 2016 15:39:23 +0200 >> >> I think the right thing here is to use the mkostemp gnulib module >> instead and pass O_BINARY in the flags. I have made this change in >> git; please let me know if it causes problems for you. > > I'm sure it will DTRT, but it's hard for me to test such changes out > of Git. Understood. As I mentioned there is a service that rolls tarballs from git: https://hydra.nixos.org/job/gnu/guile-2-0/tarball Just choose the latest one, in this case: https://hydra.nixos.org/build/37980471/download/4/guile-2.0.12.10-141e.tar.xz Cheers, Andy ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MinGW-related patches that were reported in 2014 but not applied 2016-07-16 11:24 ` Eli Zaretskii 2016-07-16 13:39 ` Andy Wingo @ 2016-07-23 12:15 ` Andy Wingo 2016-07-23 13:07 ` Eli Zaretskii 1 sibling, 1 reply; 13+ messages in thread From: Andy Wingo @ 2016-07-23 12:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: guile-devel On Sat 16 Jul 2016 13:24, Eli Zaretskii <eliz@gnu.org> writes: > From f55f1e8de40b38cc745a930bf5a374c73d3c67ce Mon Sep 17 00:00:00 2001 > From: Eli Zaretskii <eliz@gnu.org> > Date: Sat, 16 Jul 2016 14:22:06 +0300 > Subject: [PATCH] Fix 'strftime' for MS-Windows > > * libguile/stime.c (scm_strftime) [__MINGW32__]: Don't use the > trick of appending "0" to the time-zone string, Windows runtime > doesn't support that. > +#ifndef __MINGW32__ > + /* Don't do this for MinGW: it only supports fixed-format > + TTTnnnDDD TZ specifications, and gets confused if a zero is > + appended. */ This patch disables the setzone() call entirely; seems to be the wrong thing, given that MinGW doesn't appear to have struct tm->tm_zone. What if we just disable appending the 0 to the time zone? Andy ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MinGW-related patches that were reported in 2014 but not applied 2016-07-23 12:15 ` Andy Wingo @ 2016-07-23 13:07 ` Eli Zaretskii 2016-07-23 20:36 ` Andy Wingo 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2016-07-23 13:07 UTC (permalink / raw) To: Andy Wingo; +Cc: guile-devel > From: Andy Wingo <wingo@pobox.com> > Cc: guile-devel@gnu.org > Date: Sat, 23 Jul 2016 14:15:06 +0200 > > > * libguile/stime.c (scm_strftime) [__MINGW32__]: Don't use the > > trick of appending "0" to the time-zone string, Windows runtime > > doesn't support that. > > +#ifndef __MINGW32__ > > + /* Don't do this for MinGW: it only supports fixed-format > > + TTTnnnDDD TZ specifications, and gets confused if a zero is > > + appended. */ > > This patch disables the setzone() call entirely; seems to be the wrong > thing, given that MinGW doesn't appear to have struct tm->tm_zone. What > if we just disable appending the 0 to the time zone? I'm not sure I understand what you have in mind, but if you show a patch and a simple test, I can run it here. Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MinGW-related patches that were reported in 2014 but not applied 2016-07-23 13:07 ` Eli Zaretskii @ 2016-07-23 20:36 ` Andy Wingo 2016-07-24 15:10 ` Eli Zaretskii 0 siblings, 1 reply; 13+ messages in thread From: Andy Wingo @ 2016-07-23 20:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: guile-devel On Sat 23 Jul 2016 15:07, Eli Zaretskii <eliz@gnu.org> writes: >> From: Andy Wingo <wingo@pobox.com> >> Cc: guile-devel@gnu.org >> Date: Sat, 23 Jul 2016 14:15:06 +0200 >> >> > * libguile/stime.c (scm_strftime) [__MINGW32__]: Don't use the >> > trick of appending "0" to the time-zone string, Windows runtime >> > doesn't support that. >> > +#ifndef __MINGW32__ >> > + /* Don't do this for MinGW: it only supports fixed-format >> > + TTTnnnDDD TZ specifications, and gets confused if a zero is >> > + appended. */ >> >> This patch disables the setzone() call entirely; seems to be the wrong >> thing, given that MinGW doesn't appear to have struct tm->tm_zone. What >> if we just disable appending the 0 to the time zone? > > I'm not sure I understand what you have in mind, but if you show a > patch and a simple test, I can run it here. The current code: #if !defined (HAVE_STRUCT_TM_TM_ZONE) /* it seems the only way to tell non-GNU versions of strftime what zone to use (for the %Z format) is to set TZ in the environment. interrupts and thread switching must be deferred until TZ is restored. */ char **oldenv = NULL; SCM zone_spec = SCM_SIMPLE_VECTOR_REF (stime, 10); int have_zone = 0; if (scm_is_true (zone_spec) && scm_c_string_length (zone_spec) > 0) { /* it's not required that the TZ setting be correct, just that it has the right name. so try something like TZ=EST0. using only TZ=EST would be simpler but it doesn't work on some OSs, e.g., Solaris. */ SCM zone = scm_string_append (scm_list_2 (zone_spec, scm_from_locale_string ("0"))); have_zone = 1; SCM_CRITICAL_SECTION_START; oldenv = setzone (zone, SCM_ARG2, FUNC_NAME); } #endif You said that appending the 0 confuses MinGW, so you skip this section and the corresponding one after the nstrftime. But you're skipping the setzone too, so I don't see how the strftime tests would work. According to POSIX, our TZ value is valid: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html What is the MinGW restriction? You mention it in the comment but I don't understand the comment. Andy ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MinGW-related patches that were reported in 2014 but not applied 2016-07-23 20:36 ` Andy Wingo @ 2016-07-24 15:10 ` Eli Zaretskii 0 siblings, 0 replies; 13+ messages in thread From: Eli Zaretskii @ 2016-07-24 15:10 UTC (permalink / raw) To: Andy Wingo; +Cc: guile-devel > From: Andy Wingo <wingo@pobox.com> > Cc: guile-devel@gnu.org > Date: Sat, 23 Jul 2016 22:36:17 +0200 > > >> > * libguile/stime.c (scm_strftime) [__MINGW32__]: Don't use the > >> > trick of appending "0" to the time-zone string, Windows runtime > >> > doesn't support that. > >> > +#ifndef __MINGW32__ > >> > + /* Don't do this for MinGW: it only supports fixed-format > >> > + TTTnnnDDD TZ specifications, and gets confused if a zero is > >> > + appended. */ > >> > >> This patch disables the setzone() call entirely; seems to be the wrong > >> thing, given that MinGW doesn't appear to have struct tm->tm_zone. What > >> if we just disable appending the 0 to the time zone? > > > > I'm not sure I understand what you have in mind, but if you show a > > patch and a simple test, I can run it here. > > The current code: > > #if !defined (HAVE_STRUCT_TM_TM_ZONE) > /* it seems the only way to tell non-GNU versions of strftime what > zone to use (for the %Z format) is to set TZ in the > environment. interrupts and thread switching must be deferred > until TZ is restored. */ > char **oldenv = NULL; > SCM zone_spec = SCM_SIMPLE_VECTOR_REF (stime, 10); > int have_zone = 0; > > if (scm_is_true (zone_spec) && scm_c_string_length (zone_spec) > 0) > { > /* it's not required that the TZ setting be correct, just that > it has the right name. so try something like TZ=EST0. > using only TZ=EST would be simpler but it doesn't work on > some OSs, e.g., Solaris. */ > SCM zone = > scm_string_append (scm_list_2 (zone_spec, > scm_from_locale_string ("0"))); > > have_zone = 1; > SCM_CRITICAL_SECTION_START; > oldenv = setzone (zone, SCM_ARG2, FUNC_NAME); > } > #endif > > You said that appending the 0 confuses MinGW, so you skip this section > and the corresponding one after the nstrftime. But you're skipping the > setzone too, so I don't see how the strftime tests would work. Appending 0 confuses MinGW because time-zone strings on Windows can be something like "Jerusalem Standard Time", in which case appending 0 will not DTRT. If the TZ string is a 3-letter name like EST, then EST0 will indeed work on Windows. But what setzone does causes much more trouble: it replaces the environ array with one that has a single variable TZ, and that confuses the heck out of the Windows C runtime. Windows programs cannot run with an empty environ. Frankly, I don't understand why all this stuff with setzone is needed, because on Windows all that's required to do what I think this code is trying to do is this: putenv ("TZ=whatever"); tzset (); tm->tm_isdst = 0; The last bit is required for when the "whatever" zone doesn't have a DST name (like "EDT"), in which case %Z will produce an empty string. The code already does call tzset, so it should simply call putenv and set the isdst member, instead of using this strange method implemented in setzone. Am I missing something? > According to POSIX, our TZ value is valid: > > http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html > > What is the MinGW restriction? You mention it in the comment but I > don't understand the comment. If you are asking about the forms of the TZ variable, they are documented here: https://msdn.microsoft.com/en-us/library/90s5c885(v=vs.71).aspx But that's not the important problem with setzone. Of course, the same problems exist with localtime and mktime: they should also call putenv instead of setzone. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MinGW-related patches that were reported in 2014 but not applied 2016-07-15 19:04 MinGW-related patches that were reported in 2014 but not applied Eli Zaretskii 2016-07-16 8:33 ` Andy Wingo @ 2016-07-17 6:04 ` Andy Wingo 1 sibling, 0 replies; 13+ messages in thread From: Andy Wingo @ 2016-07-17 6:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: guile-devel On Fri 15 Jul 2016 21:04, Eli Zaretskii <eliz@gnu.org> writes: > The issues with dirname and basename, for which I posted a patch here: > > https://lists.gnu.org/archive/html/guile-devel/2014-07/msg00012.html > > were subsequently discussed, but the code was not changed, AFAICT. I think we want to go with Gnulib here, as Ludovic mentioned in the response to this mail. I guess we should convert the string to UTF-8, call gnulib's dir_name and base_name on it. Done, will push shortly. Andy ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MinGW-related patches that were reported in 2014 but not applied @ 2016-07-22 10:21 Eli Zaretskii 2016-07-23 11:51 ` Andy Wingo 0 siblings, 1 reply; 13+ messages in thread From: Eli Zaretskii @ 2016-07-22 10:21 UTC (permalink / raw) To: guile-devel Ping! Two out of 3 patches sent here: https://lists.gnu.org/archive/html/guile-devel/2016-07/msg00085.html are still waiting to be accepted. Thanks. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: MinGW-related patches that were reported in 2014 but not applied 2016-07-22 10:21 Eli Zaretskii @ 2016-07-23 11:51 ` Andy Wingo 0 siblings, 0 replies; 13+ messages in thread From: Andy Wingo @ 2016-07-23 11:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: guile-devel On Fri 22 Jul 2016 12:21, Eli Zaretskii <eliz@gnu.org> writes: > Ping! Two out of 3 patches sent here: > > https://lists.gnu.org/archive/html/guile-devel/2016-07/msg00085.html > > are still waiting to be accepted. I pushed the basename/dirname patch, using dirname-lgpl from gnulib as Ludo had suggested many moons ago. Just the strftime one remaining. Tx for the ping. Andy ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-07-24 15:10 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-07-15 19:04 MinGW-related patches that were reported in 2014 but not applied Eli Zaretskii 2016-07-16 8:33 ` Andy Wingo 2016-07-16 11:24 ` Eli Zaretskii 2016-07-16 13:39 ` Andy Wingo 2016-07-16 15:37 ` Eli Zaretskii 2016-07-23 9:58 ` Andy Wingo 2016-07-23 12:15 ` Andy Wingo 2016-07-23 13:07 ` Eli Zaretskii 2016-07-23 20:36 ` Andy Wingo 2016-07-24 15:10 ` Eli Zaretskii 2016-07-17 6:04 ` Andy Wingo -- strict thread matches above, loose matches on Subject: below -- 2016-07-22 10:21 Eli Zaretskii 2016-07-23 11:51 ` Andy Wingo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).