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]" Date: Fri, 5 May 2017 23:43:16 +0300 Message-ID: Subject: Re: Bug in timestamp arithmetic To: djgpp AT delorie DOT com Content-Type: text/plain; charset=UTF-8 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 Precedence: bulk On 5/5/17, Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via 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.