delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2016/05/20/00:23:05

X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:date:message-id:from:to:subject:in-reply-to
:references:mime-version:content-type; q=dns; s=default; b=jMlhd
YDccHMyocHv02ZmZFAvnWjPFQQvw/SZYYX6b2fSCMkfqAyf5PcFU4z1rQ2QTWFbc
1ZlQZaw3Z4JxuOCsbwq04S0IYlyxdrDrL/IAYfXQvkbaJr63O0HRgOwtaK5UGvwn
+7lrJcIzefErBf622tAaKGj4BCcrNlM31ADaaA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:date:message-id:from:to:subject:in-reply-to
:references:mime-version:content-type; s=default; bh=vD9PfMBvSUK
zuxwYwMnJOe0uYTc=; b=oiQvApZ5VfqgJL5VSWU/89H7tZ0GQcodprp/cvjgbWA
ZoV7VlV5AnY7M0MVjPowkxOy0YvWIIBzp8LnMDdVC2ebygtI2ESSRlNUw9F1xg9U
+vCOatJwptoYDI/X6EidzwHah9AqxlU+/ufjST6OWGnIlwoW0GiAkXrfJPM5ELKs
=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=bg, BG, $B!G, $b!g
X-HELO: mgwym02.jp.fujitsu.com
X-SecurityPolicyCheck: OK by SHieldMailChecker v2.2.3
X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20140219-2
Date: Fri, 20 May 2016 13:22:31 +0900
Message-ID: <o8x8tz573zs.wl-koba@jp.fujitsu.com>
From: KOBAYASHI Shinji <koba AT jp DOT fujitsu DOT com>
To: cygwin AT cygwin DOT com
Subject: Invalid tm_zone from localtime() when TZ is not set
In-Reply-To: <932D033F-9DA4-4901-9158-328AA929FEC8@etr-usa.com>
References: <o8xeg8x7e2r DOT wl-koba AT jp DOT fujitsu DOT com> <932D033F-9DA4-4901-9158-328AA929FEC8 AT etr-usa DOT com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-unknown-cygwin) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
X-TM-AS-MML: disable
X-IsSubscribed: yes

>>>>>	Warren Young  wrote:
> How about you just give the line of code and explain what$B!G(Bs wrong with it?  Then someone with checkin rights can reimplement your change from your prose description.

Thank you for your suggestion. So I try to describe the problem:

Current localtime() can return invalid tm_zone when used with
non-English Windows and the TZ environment variable is unset. This
leads to a failure of importing time module in Python 3:

% (unset TZ; python3 -c "import time")
Traceback (most recent call last):
  File "<string>", line 1, in <module>
SystemError: initialization of time raised unreported exception

Although most users set the TZ environment variable, tox (>= 2.0)
drops most environment variables including TZ by default when invoking
test environments. So the users of tox on non-English Windows may
suffer from this problem.

localtime() calls tzsetwall() when TZ is not set. In tzsetwall(),
the StandardName and DaylightName member values retrieved by
GetTimeZoneInformation() are checked with isupper() and copied to the
char[] buffer used as the timezone name in tzparse(). However, the
type of these member values are wchar_t and isupper() is defined only
when isascii() is true. So it may happen that the char[] buffer
contains invalid characters as a result of implicit cast from wchar_t
to char.

The return value of isupper() for non-ascii characters depends on
other data, because an out of bounds access occurs for the small
(128 + 256) table used in isupper(). I confirmed the above error on
Japanese Windows with 64-bit Cygwin 2.5.0-1 and 2.5.1-1, but had no
problem with 64-bit Cygwin 2.4.1-1 nor with 32-bit Cygwins.

So, I propose to call isascii() to assure the wchar_t fits in the
range of ASCII before calling isupper().

I have considered some other methods:

1. Using iswupper() instead of isupper().
   - Although this method is effective for Japanese environments, it
     is not assured that the character iswupper() returns true fits in
     the range of ASCII.
2. Add (char) cast to the argument of isupper().
   - This method assures that the copied characters are uppercase
     only. However, it may be different from original characters due
     to casting.

So I think that adding isascii() calls is better than these methods.

Regards,

KOBAYASHI Shinji.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019