From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1208 Path: news.gmane.org!not-for-mail From: Eric Blake Newsgroups: gmane.comp.lib.gnulib.bugs,gmane.linux.lib.musl.general Subject: Re: [musl] Re: musl bugs found through gnulib Date: Tue, 19 Jun 2012 22:10:11 -0600 Organization: Red Hat Message-ID: <4FE14D23.60901@redhat.com> References: <20120609230541.47eac2de@newbook> <4FD55156.7050302@cs.ucla.edu> <20120611182202.1ee4d019@newbook> <12545931.v3ALTEUUx8@linuix> <20120620030445.GU163@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig94D53EF019757EC0088AED72" X-Trace: dough.gmane.org 1340165438 28192 80.91.229.3 (20 Jun 2012 04:10:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 20 Jun 2012 04:10:38 +0000 (UTC) Cc: bug-gnulib@gnu.org, Isaac Dunham , Paul Eggert , musl@lists.openwall.com, Reuben Thomas To: Rich Felker Original-X-From: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Wed Jun 20 06:10: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 1ShCFS-0007fv-OW for gnu-bug-gnulib@m.gmane.org; Wed, 20 Jun 2012 06:10:30 +0200 Original-Received: from localhost ([::1]:35754 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShCFS-0005IL-C0 for gnu-bug-gnulib@m.gmane.org; Wed, 20 Jun 2012 00:10:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:53271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShCFO-0005Hv-3J for bug-gnulib@gnu.org; Wed, 20 Jun 2012 00:10:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ShCFL-00035D-MU for bug-gnulib@gnu.org; Wed, 20 Jun 2012 00:10:25 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:15798) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShCFL-00034p-Er for bug-gnulib@gnu.org; Wed, 20 Jun 2012 00:10:23 -0400 Original-Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5K4ADLB011328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jun 2012 00:10:13 -0400 Original-Received: from [10.3.113.131] (ovpn-113-131.phx2.redhat.com [10.3.113.131]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q5K4ABY0032170; Wed, 20 Jun 2012 00:10:11 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 In-Reply-To: <20120620030445.GU163@brightrain.aerifal.cx> X-Enigmail-Version: 1.4.2 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.132.183.28 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:31072 gmane.linux.lib.musl.general:1208 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig94D53EF019757EC0088AED72 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 06/19/2012 09:04 PM, Rich Felker wrote: >> Replacement of duplocale, because of >> checking whether duplocale(LC_GLOBAL_LOCALE) works... no >=20 > POSIX does not specify any use of LC_GLOBAL_LOCALE except as an > argument to uselocale. Is there a reason it's needed? Perhaps more > importantly, is the replacement when libc doesn't provide this > functionality bloated/painful? Unfortunately, you are out of date. POSIX _does_ require duplocale(LC_GLOBAL_LOCALE) to work: http://austingroupbugs.net/view.php?id=3D301 If the locobj argument is LC_GLOBAL_LOCALE, duplocale() shall create a new locale object containing a copy of the global locale determined by the setlocale() function. The behavior is undefined if the locobj argument is not a valid locale object handle. After line 24978 add a new paragraph to APPLICATION USAGE: The duplocale() function can also be used in conjunction with uselocale((locale_t)0). This returns the locale in effect for the calling thread, but can have the value LC_GLOBAL_LOCALE. Passing LC_GLOBAL_LOCALE to functions such as isalnum_l() results in undefined behavior, but applications can convert it into a usable locale object by using duplocale(). >> test-fcntl.c:382: assertion failed >> FAIL: test-fcntl >=20 > This is caused by the fact that the F_GETOWN fcntl on Linux is broken; > there's no way to distinguish error returns from non-error negative > return values. So we never set errno when calling F_GETOWN and assume > the return value is not an error. There's a new-ish Linux-specific > F_GETOWN_EX we could use when it's available, but the fallback code > would still fail just like it does now, because it's a fundamental > limitation in the API. Yes, Linux 2.6.32 introduced F_GETOWN_EX for precisely this reason, and you should be using it. >> test-grantpt.c:34: assertion failed >> FAIL: test-grantpt >=20 > This is an invalid test. POSIX specifies this function "may fail", not > "shall fail", and since the function is inherently a no-op, it would > be idiotic to make it perform a syscall to check the validity of the > file descriptor... This is one of the cases where gnulib prefers to emulate the shall fail semantics of glibc, as they are more useful to program around. >> test-ptsname_r.c:118: assertion failed >> FAIL: test-ptsname_r >=20 > It's testing that ptsname_r both sets errno and returns the error > code, and that they're the same. Since this function is nonstandard, > there's no spec for it, so perhaps this is desirable; I was assuming > it should return -1 on failure. There _is_ a proposed standard for it now: http://austingroupbugs.net/view.php?id=3D508 which requires only the return value to be 0 or an errno value, and not that errno be set. gnulib should only be checking for a valid return val= ue. >=20 >> test-strerror_r.c:118: assertion failed >> FAIL: test-strerror_r >=20 > This test is looking for a null terminator at the n-1 position of the > buffer if strerror_r fails with ERANGE (buffer too small). I don't see > anywhere the function is specified to write to the buffer AT ALL on > failure, so this test seems invalid. This is a case where POSIX is rather weak, but where quality of implementation demands that the most useful interface is one that provides the most information back to the user. glibc had a number of bugs that were fixed in this area to improve QoI, and gnulib now prefers to rely on those improvements. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enig94D53EF019757EC0088AED72 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJP4U0jAAoJEKeha0olJ0NqO7EIAJTBMd2+yKaud3gsjEHzO6cO Mvdpdx/hzVGs88YG8YQEw9f2EfHeSleBMplzBFLkWy/3mV9SMM56hSGIf/LrmCoM 0bXCQ6WMz9WGqzXGK/fzOorxRWjRB0xURh8CXweF+MtNRg91RP54ycRfAv3+T14S S7/XmFJBO33ZPOQG86z1mtS12vi+C0bJahqcKzLBqXTyYSzEz8y5oChwtuhOgO5T W8XCpngTyEAfqlf6O3CRIWw/nIqTJVQH4Nag4PQugcbxEF6AFQEL66RrBJ2A2lqj PAYTWb+tm9mqCMyRX/JllP/SgtVhSR/9Euvc/DY/E+/Ewo5DOCvc0XpaldyG5vc= =BQ5d -----END PGP SIGNATURE----- --------------enig94D53EF019757EC0088AED72--