From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1169 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: musl bugs found through gnulib Date: Sun, 17 Jun 2012 20:29:19 -0400 Message-ID: <20120618002919.GA163@brightrain.aerifal.cx> References: <54705.50.0.229.11.1339977923.squirrel@lavabit.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1339979614 16281 80.91.229.3 (18 Jun 2012 00:33:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 18 Jun 2012 00:33:34 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1170-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 18 02:33:34 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SgPuP-0004r0-KS for gllmg-musl@plane.gmane.org; Mon, 18 Jun 2012 02:33:33 +0200 Original-Received: (qmail 23677 invoked by uid 550); 18 Jun 2012 00:33:33 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 23669 invoked from network); 18 Jun 2012 00:33:33 -0000 Content-Disposition: inline In-Reply-To: <54705.50.0.229.11.1339977923.squirrel@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1169 Archived-At: On Sun, Jun 17, 2012 at 05:05:23PM -0700, idunham@lavabit.com wrote: > > 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...")? The EBADF error is a "may fail", not a "shall fail", per POSIX. Since it requires an extra syscall in the general case (although in some special cases, we're already making a syscall that could detect EBADF), I find it's probably just an undesirable performance hit. Applications should interpret the "may fail" as meaning it's not valid/portable to call fdopen with an invalid file descriptor and assume you can get a FILE* that will generate EBADF when it's used later, not as meaning that the implementation will do their error-checking for them. > > Replacement of futimens, because of > > checking whether futimens works... no > Could be a bug. See the #ifdef __linux__ in the test file. Due to old buggy kernels, they ALWAYS consider futimens broken on Linux. > > Replacement of getcwd, because of > > checking whether getcwd handles long file names properly... no, but it > > is partly working > Is this a test for ERANGE handling (error on name >= 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 =< cwd_length. If size !< > (cwd_length + 1), that is conformant behavior. (See man 3posix getcwd) I think musl is correct on everything for getcwd, but I'd like to double-check. > > Replacement of getopt, because of > > checking whether getopt is POSIX compatible... no > We'd need to see this test...(will look later). It's testing for GNU behavior not POSIX behavior. > > 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"... Same. > > 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/UTF32 > yet. It does. musl's iconv supports all UTFs (but no endian auto-detection; explicit endianness is required in the argument to iconv_open), all ISO-8859s, lots of other legacy 8bit charsets, and some legacy Chinese and Japanese charsets as source charsets only (not destination). > > 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. Yes, I'm looking into these as possible bugs, but I don't think anything's wrong with perror... > > 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... Well gnulib wants to offer this API, so if it doesn't exist, gnulib must provide it.. Rich