guile-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]