From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9115 invoked from network); 12 Nov 2020 04:08:13 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 12 Nov 2020 04:08:13 -0000 Received: (qmail 26135 invoked by uid 550); 12 Nov 2020 04:08:11 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26111 invoked from network); 12 Nov 2020 04:08:10 -0000 Date: Wed, 11 Nov 2020 23:07:57 -0500 From: Rich Felker To: Paul Eggert Cc: Bruno Haible , bug-gnulib@gnu.org, Simon Josefsson , =?utf-8?Q?P=C3=A1draig?= Brady , musl@lists.openwall.com Message-ID: <20201112040755.GR534@brightrain.aerifal.cx> References: <87o8k4urq2.fsf@latte.josefsson.org> <4957782.yBLirf3sRb@omega> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: parse-datetime test failure On Wed, Nov 11, 2020 at 07:38:00PM -0800, Paul Eggert wrote: > On 11/11/20 8:20 AM, Bruno Haible wrote: > >It works fine on Alpine Linux 3.7 (32-bit, 64-bit) and 3.9 (64-bit). > > > >On Alpine Linux 3.10 and 3.12 (64-bit) it fails: > >../../gltests/test-parse-datetime.c:448: assertion 'result.tv_sec == 1 * 60 * 60 + 2 * 60 + 3 && result.tv_nsec == 123456789' failed > >Aborted > > > >So, to me it looks like a regression between Alpine Linux 3.9 and 3.10. > > It's arguably a bug in the test case, since Alpine uses musl libc > which does not support time zone abbreviations longer than 6 bytes, > whereas the test case uses an time zone abbreviation of 2000 bytes > (to test a bug in an old Gnulib version when running on GNU/Linux). > POSIX does not define behavior if you go over the limit. > > I worked around the problem by changing the test case to not go over > the limit as determined by sysconf (_SC_TZNAME_MAX), in the first > attached patch. Plus I refactored and/or slightly improved the > Gnulib overflow checking while I was in the neighborhood (last two > attached patches). > > Arguably this is a quality-of-implementation issue here, since > Alpine and/or musl goes beserk with long timezone abbreviations > whereas every other implementation I know of either works or > silently substitutes localtime or UTC (which is good enough for this > test case). But I'll leave that issue to the Alpine and/or musl libc > folks. > > I'll cc this to the musl bug reporting list. Although the Gnulib > test failure has been fixed, it may be the symptom of a more-severe > bug in musl. For those new to the problem, this thread starts here: > > https://lists.gnu.org/r/bug-gnulib/2020-11/msg00039.html Thanks. I believe you've just re-discovered a known bug that's fixed in musl commit 33338ebc853d37c80f0f236cc7a92cb0acc6aace, which will be included in the upcoming 1.2.2 release. Rich