From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1167 Path: news.gmane.org!not-for-mail From: idunham@lavabit.com Newsgroups: gmane.comp.lib.gnulib.bugs,gmane.linux.lib.musl.general Subject: Re: [musl] Re: musl bugs found through gnulib Date: Sun, 17 Jun 2012 17:05:23 -0700 (PDT) Message-ID: <54705.50.0.229.11.1339977923.squirrel@lavabit.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1339977935 7410 80.91.229.3 (18 Jun 2012 00:05:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Jun 2012 00:05:35 +0000 (UTC) Cc: Isaac Dunham , Paul Eggert , bug-gnulib@gnu.org, Reuben Thomas To: musl@lists.openwall.com Original-X-From: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Mon Jun 18 02:05:33 2012 Return-path: Envelope-to: gnu-bug-gnulib@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SgPTI-0002UA-6b for gnu-bug-gnulib@m.gmane.org; Mon, 18 Jun 2012 02:05:32 +0200 Original-Received: from localhost ([::1]:44056 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgPTI-0005Ej-23 for gnu-bug-gnulib@m.gmane.org; Sun, 17 Jun 2012 20:05:32 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33810) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgPTE-0005Ed-Og for bug-gnulib@gnu.org; Sun, 17 Jun 2012 20:05:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SgPTC-0002XK-Jg for bug-gnulib@gnu.org; Sun, 17 Jun 2012 20:05:28 -0400 Original-Received: from karen.lavabit.com ([72.249.41.33]:36769) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SgPTC-0002XB-DL for bug-gnulib@gnu.org; Sun, 17 Jun 2012 20:05:26 -0400 Original-Received: from a.earth.lavabit.com (a.earth.lavabit.com [192.168.111.10]) by karen.lavabit.com (Postfix) with ESMTP id 1023A11B837; Sun, 17 Jun 2012 19:05:24 -0500 (CDT) Original-Received: from lavabit.com (50-0-229-11.dsl.static.sonic.net [50.0.229.11]) by lavabit.com with ESMTP id GW9S8L64HUCI; Sun, 17 Jun 2012 19:05:24 -0500 Original-Received: from 50.0.229.11 (SquirrelMail authenticated user idunham) by lavabit.com with HTTP; Sun, 17 Jun 2012 17:05:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=etAVJuHNQPMaQL1o72If63HN7Aodx5czKiK6QmtFhDN3eMpgqh48ZMgPCy7OSllRL8rlLBsyFahfVKWYrJ+z+xlqCKGc05aspMuKAhndWApd2H26ANTw32tYZTi8pQvTjQVCHQRnhdofdhd3cgFyOy1mAvrlhF03nYIjLGo7zpg=; h=Message-ID:Date:Subject:From:To:Cc:User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding; User-Agent: SquirrelMail/1.4.13 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Received-From: 72.249.41.33 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Original-Sender: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Xref: news.gmane.org gmane.comp.lib.gnulib.bugs:30994 gmane.linux.lib.musl.general:1167 Archived-At: > [CCing the musl list] > Isaac Dunham wrote in > : >> musl is designed for standards conformance, > > There is a recipe, in = , > that explains how to use gnulib to check a libc against bugs. Be warned: a bad test can cause failures as well. It's been one of the musl developers' complaints about gnulib that the tests are buggy and frequently check for glibc behavior instead of standard behavior. > When I apply this to musl-0.9.1, I get this list of problems: > > Replacements of *printf, because of > checking whether printf supports infinite 'long double' arguments... = no > checking whether printf supports the 'ls' directive... no > checking whether printf survives out-of-memory conditions... no At least one of these (infinite long double, IIRC) is invalid or a test for a GNU-ism. This was previously discussed on the musl ML. OOM behavior is undefined AFAICT (feel free to point out a standard), and the scenario is a lot less likely with musl than glibc for several reasons. > Replacement of duplocale, because of > checking whether duplocale(LC_GLOBAL_LOCALE) works... no Need to check this one > Replacement of fdopen, because of > checking whether fdopen sets errno... no I presume this is nonconformance to POSIX ("otherwise, a null pointer shall be returned and errno set...")? > Replacement of futimens, because of > checking whether futimens works... no Could be a bug. > Replacement of getcwd, because of > checking whether getcwd handles long file names properly... no, but i= t > is partly working Is this a test for ERANGE handling (error on name >=3D size)? Other than that, I see no specification covering this. > checking whether getcwd aborts when 4k < cwd_length < 16k... no AFAICT, only required to error when size =3D< cwd_length. If size !< (cwd_length + 1), that is conformant behavior. (See man 3posix getcwd) > Replacement of getopt, because of > checking whether getopt is POSIX compatible... no We'd need to see this test...(will look later). > Replacement of glob, because of > checking for GNU glob interface version 1... no > (not sure this is a bug or just an incompatibility compared to glibc) Looks like an incompatability, since it specifies "GNU interface"... > Replacement of iconv and iconv_open, because of > checking whether iconv supports conversion between UTF-8 and > UTF-{16,32}{BE,LE}... no Not "nonconformant" from the standpoint of POSIX, AFAICT, but it is incomplete. musl is UTF8 native, but I don't think it supports UTF16/UTF3= 2 yet. > Replacement of mktime, because of > checking for working mktime... no > Replacement of perror, because of > checking whether perror matches strerror... no > Replacement of popen, because of > checking whether popen works with closed stdin... no Look like bugs, if the description is correct. > Replacement of regex, because of > checking for working re_compile_pattern... no This is #ifdef __USE_GNU I'm not aware of any standard covering GNU APIs... > Replacement of strtod, because of > checking whether strtod obeys C99... no > > For each of the replacements, first look at the test program's results > (in config.log), then look at the test program's source code (in m4/*.m= 4). > Thanks, Isaac Dunham