[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MinGW-related patches that were reported in 2014 but not applied
From: |
Andy Wingo |
Subject: |
Re: MinGW-related patches that were reported in 2014 but not applied |
Date: |
Sat, 23 Jul 2016 22:36:17 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
On Sat 23 Jul 2016 15:07, Eli Zaretskii <address@hidden> writes:
>> From: Andy Wingo <address@hidden>
>> Cc: address@hidden
>> 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
Re: MinGW-related patches that were reported in 2014 but not applied, Andy Wingo, 2016/07/23