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:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; q=dns; s=default; b=R83AFpOnY8+ewheHhDdA0FhIietr
	O3bew8l7OM2B38eDsyXiXpjCQdjrM29xSXLJuxjXE9CqIBYOi9BAxS7Wiu9GY5Dg
	SMvC1cRzrzJ3rAxkF17Jzj4TKyOZWgEskvySgBMATY0OwMhIrT9euUNpiqiZHEkp
	xFWGVOgrWdKmsOU=
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:content-type:mime-version:subject:from
	:in-reply-to:date:content-transfer-encoding:message-id
	:references:to; s=default; bh=JvVKCUz4KL+CcFv8BN99uH+KtBw=; b=Gq
	nQNoD+qBa81v8LMt2/OZ86iznWQmWqTdOEa3RE8qOQAr8XLoVoHuHoo/LxxvK9A3
	e8+dbUog09ySbb1mVLOXKbhiaKBCw/2ggkbrvjiUWwL/xTLc4TqsJigDtgFP8SIb
	qZ9LyR217i0wLjrxLjr7QakAaG2uwl6w49cB7tZhw=
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
X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE autolearn=ham version=3.3.1
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Subject: Re: mktime loop
From: Denis Excoffier <cygwin AT Denis-Excoffier DOT org>
In-Reply-To: <20130514133950.GC23910@calimero.vinschen.de>
Date: Thu, 16 May 2013 19:13:34 +0200
Message-Id: <42B24E55-427E-4FDA-AF61-9732C9E9611B@Denis-Excoffier.org>
References: <5244063b734b165baf34bdebaff0aca5 AT denis-excoffier DOT org> <20130513153651 DOT GD5045 AT calimero DOT vinschen DOT de> <20130513154921 DOT GF8890 AT calimero DOT vinschen DOT de> <27BBE8FE-303A-432D-94AA-AF834124D125 AT Denis-Excoffier DOT org> <20130513165712 DOT GH8890 AT calimero DOT vinschen DOT de> <20130514133950 DOT GC23910 AT calimero DOT vinschen DOT de>
To: cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id r4GHE1S8026574


On 2013-05-14 15:39, Corinna Vinschen wrote:
> On May 13 18:57, Corinna Vinschen wrote:
>> On May 13 18:41, Denis Excoffier wrote:
>>> On 2013-05-13 17:49, Corinna Vinschen wrote:
>>>> Erm... hang on.  Is that really a problem?  2147483647 is 0x7fffffff,
>>>> which is the maximum you get with a 4 byte time_t (== signed long)
>>>> anyway.  If you switch the date to 2038-01-20, the value will be
>>>> negative, and therefore outside the scope of the 4 byte time_t.  So this
>>>> is a hard restriction of using 4 byte time_t.
>>>> 
>>>> The solution is:
>>>> 
>>>> - Either somebody changes 32 bit Cygwin to 8 byte time_t while keeping
>>>> all the 4 byte time_t APIs intact to maintain compatibility with
>>>> existing binaries(*),
>>>> 
>>>> - or, you switch to a 64 bit Windows and use 64 bit Cygwin ;)
>>>> 
>>> I understand.
>>> 
>>> I suppose you will however be willing to provide us a means to workaround
>>> the "autoconf mktime usability test failing" (see for example in
>>> gawk-4.1.0 where all the tm fields are set to 128). Now, instead of only
>>> failing (i presume), it hangs. Sorry, this specific point should have been
>>> noticed in my original post.
>>> 
>>> Or do we have to patch every impacted ./configure?
>> 
>> Good point.  I guess the right thing to do here is for mktime to
>> return -1 instead of hanging.  I look into that.
> 
> Looks like this is a result of gcc optimization settings.  The upstream
> code computing time_t <-> struct tm conversions requires integer
> overflow to be fully defined, but gcc's -O2 option sets
> -fstrict-overflow which results in all kinds of agressive integer
> optimizations which disabled utilizing integer overflows for serious
> purposes.  I fixed that by setting the -fwrapv option when building the
> affected localtime.cc file (thanks to Kai Tietz for pointing this out).
> 
I can confirm that the last snapshot (20130516) fixes the problem.

Thank you.

Denis Excoffier.
--
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