X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
	bh=82Z9ViTB7wQUF8SkiFjWnwS3cBIZI4+rEMWK+X1s/SU=;
	b=o17CbDFRO46ser0s4iELRYwoPDpDJoe3QD65YiYbqWBT4LfA4yfvuzcCLf9ByO/jzx
	8GVn2V82MLud39eNE5VORDy8Nd9LihOxdsH/neRaYDb3fnif6vbexNDmyVgQ+F9eDv09
	z/bx5Dhz6NtX3yEy0X9P2bgbnamRHs+Uu70P9b/ni8atF1WeHkxwYO6AQOsq6lrenRGi
	KxCVZyOuo13G3xmJQsQo8H67alzC/os8obPEwNQHCYXlipnjuNi+Z5Jk9tHo7v50e7QV
	sBMiBOaiP2Dlqvlh7EzH+B24qQ2nnXXGhcKFtFkxID1u9Uwp3ictep7YzNk+PNSNCvSn
	CbnA==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=82Z9ViTB7wQUF8SkiFjWnwS3cBIZI4+rEMWK+X1s/SU=;
	b=Iei21P3+FTzr/oRN4N0khGTlC4sDwN8s3EGvpVdJiKdGfMK/i8pqpadXBSLhkdlboE
	QQNmDMnqbOQgLlyRAtJ7cN9n+Yh4NSkC7MTA9UEkqyZT8sYKzQ2gdbY3czDkunw8vS8h
	LbZQxwGS84G/2pjmlHboEmSmekwGcqyQ45Xnhzu3PBQw34Qu5M5sTtRgVluGUCWcCBLE
	YnOFz/9Wh6Hgnxuq0hU75G5/osOSX6Pr8Z0So04tp2NNjfCrBKXEdHoSZKjuwuvUzZrS
	cF2tQf3LgbTmbNM5FcXKeR/AUsvr/+peKkRzqWiVTwSrvZquyzz+fyoMQyqspjErsMsY
	xaaQ==
X-Gm-Message-State:	AODbwcBKl9l8kLSq/pUZLIRhK0tZyvxF70OhG/bwCWf0OoVKkay6vYAJ
	Yympsdf9LkZKRYeYxUdpxDgEBEaUYw==
X-Received:	by 10.55.90.2 with SMTP id o2mr15654701qkb.251.1494016997067; Fri,
	05 May 2017 13:43:17 -0700 (PDT)
MIME-Version:	1.0
In-Reply-To:	<590CCAE9.3090904@gmx.de>
References:	<6c031262-a53d-4ede-925d-ef279a2e1286 AT googlegroups DOT com> <590CCAE9 DOT 3090904 AT gmx DOT de>
From:	"Ozkan Sezer (sezeroz AT gmail DOT com) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Date:	Fri, 5 May 2017 23:43:16 +0300
Message-ID:	<CAA2C=vCmPrmtg0OQNzq28KYuDmUmzAVqi49ZOWVDcBkzzYkeVg@mail.gmail.com>
Subject:	Re: Bug in timestamp arithmetic
To:	djgpp AT delorie DOT com
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On 5/5/17, Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via
djgpp AT delorie DOT com] <djgpp AT delorie DOT com> wrote:
> Am 05.05.2017 15:27, schrieb Arrigo Marchiori (ardovm AT yahoo DOT it) [via
> djgpp AT delorie DOT com]:
>> Dear All,
>>
>> I am writing here to report a bug, as I could not do it through the
>> delorie.com web site.
>>
>> On my system, I did not install any timezone files. libc therefore
>> generates a ``default'' timezone. Such timezone has a random offset with
>> respect to GMT.
>>
>> The effect is that ctime(0) returns random values, such as "31 December
>> 1969", instead of "1 January 1970".
>>
>> This problem should be resolved by the patch you can find at the end of
>> this message.
>>
>> The patch must be applied to src/libc/ansi/time/ctime.c
>> Its effects are the following.
>>
>>   - In function tzload(): the default timezone created from
>> _posixrules_data is actually parsed. It was not, because the nread
>> variable was not updated with its size.
>>
>>   - In function tzparse(): the value for stdoffset is set to zero, if the
>> parameter lastditch is set. Before this patch, the value of stdoffset was
>> never assigned, and therefore the timezone received a random offset from
>> GMT.
>>
>>   - In function tzparse(): after a new default timezone was created inside
>> sp, the `defaulttype' field was not updated. If the default data from
>> _posixrules was loaded correctly (see first point), sp->defaulttype would
>> be set to 1. But previous types have just been overwritten, therefore this
>> attribute must be set to zero, i.e. to the only current type.
>>
>> I hope this makes sense to you. Feel free to contact me if you need any
>> more information on this, or if you think I can be of any help integrating
>> it.
>>
>> Best regards,
>>
>>
>> Arrigo
>>
>>
>> --- src/libc/ansi/time/ctime.c.orig	2014-04-19 20:50:30.000000000 +0200
>> +++ src/libc/ansi/time/ctime.c	2017-05-05 14:20:54.988023000 +0200
>> @@ -362,7 +362,7 @@
>>
>>       /* We've got a built-in copy of posixrules just in case */
>>       memcpy(buf, _posixrules_data, sizeof(_posixrules_data));
>> -    i = sizeof(_posixrules_data);
>> +    nread = sizeof(_posixrules_data);
>>     }
>>     else
>>     {
>> @@ -944,6 +944,7 @@
>>       name += stdlen;
>>       if (stdlen>= sizeof sp->chars)
>>         stdlen = (sizeof sp->chars) - 1;
>> +    stdoffset = 0;
>>     }
>>     else
>>     {
>> @@ -1156,6 +1157,7 @@
>>       sp->ttis[0].tt_gmtoff = -stdoffset;
>>       sp->ttis[0].tt_isdst = 0;
>>       sp->ttis[0].tt_abbrind = 0;
>> +    sp->defaulttype = 0;
>>     }
>>     sp->charcnt = stdlen + 1;
>>     if (dstlen != 0)
>>
>
>
> I also have usually neither TZ set nor djtzn205 installed and can verify
> the
> bug described by the poster.  An inspection of ctime.c from the repository
> shows that the implementation has the different bugs described in the post
> leading to random timestamp around 1969-12-24 for my installation.
> IMO, the fix proposed is correct and it solves the problems as explained.
> A library compiled from repository sources and with the proposed patch
> applied produces the correct value for ctime(0) with and without djtzn205
> installed.  Of course, if djtzn205 is installed, then ctime produces the
> right time string so the patch does not break anything.
> Any objections if the proposed fix is committed?

Looks OK to me.


>
> Regards,
> Juan M. Guerrero
>
>


--
O.S.

- Raw text -