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=0.1 required=5.0 tests=DKIM_ADSP_ALL, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2591 invoked from network); 12 Apr 2022 20:44:10 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 12 Apr 2022 20:44:10 -0000 Received: (qmail 23767 invoked by uid 550); 12 Apr 2022 20:44:08 -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 23735 invoked from network); 12 Apr 2022 20:44:07 -0000 Date: Tue, 12 Apr 2022 13:43:55 -0700 From: "Gary E. Miller" To: musl@lists.openwall.com Message-ID: <20220412134355.59bd920e@spidey.rellim.com> Organization: Rellim X-Mailer: Claws Mail 4.1.0 (GTK 3.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/5A3y8rJ3yzKXxj06Ttye5PX"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: [musl] =?UTF-8?B?4pyYc3RyZXJyb3Jfcigp?= bug in musl --Sig_/5A3y8rJ3yzKXxj06Ttye5PX Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Yo All! I'm new to the list. I;ve been trying to report a musl bug on #musl since last Friday, but no one seems to live there. musl (all versions) has a bug in strerror_r(). The musl reference manual says of _GNUSOURCE: _GNU_SOURCE (or _ALL_SOURCE) Adds everything above, plus interfaces modeled after GNU libc extensions and interfaces for making use of Linux-specific features. I take that to mean that when _GNU_SOURCE is used to compile code with musl that the results will behave as GNU libc (glinc). The muls code in include/string.h, line 68 says: #if defined(_POSIX_SOURCE) || defined(_POSIX_C_SOURCE) \ || defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) \ || defined(_BSD_SOURCE) char *strtok_r (char *__restrict, const char *__restrict, char **__restrict= ); int strerror_r (int, char *, size_t); [...] So strerro_r() always returns an int if _GNU_SOURCE, POSIX_SOURCE, etc. is defined. But the glibc man page for strerror_r() ssys: int strerror_r(int errnum, char *buf, size_t buflen); /* XSI-compliant */ char *strerror_r(int errnum, char *buf, size_t buflen); /* GNU-specific */ When _GNU_SOURCE is defined with glibc, then strerror_r() returns a char *. The man page continues: strerror_r(): The XSI-compliant version is provided if: (_POSIX_C_SOURCE >=3D 200112L) && ! _GNU_SOURCE Otherwise, the GNU-specific version is provided. The glibc include/string.h, line 420, clarifies things a bit: #ifdef __USE_XOPEN2K /* Reentrant version of `strerror'. There are 2 flavors of `strerror_r', GNU which returns the string and may or may not use the supplied temporary buffer and POSIX one which fills the string into the buffer. To use the POSIX version, -D_XOPEN_SOURCE=3D600 or -D_POSIX_C_SOURCE=3D2= 00112L without -D_GNU_SOURCE is needed, otherwise the GNU version is preferred. */ # if defined __USE_XOPEN2K && !defined __USE_GNU /* Fill BUF with a string describing the meaning of the `errno' code in ERRNUM. */ # ifdef __REDIRECT_NTH extern int __REDIRECT_NTH (strerror_r, (int __errnum, char *__buf, size_t __buflen), __xpg_strerror_r) __nonnull ((2)) __attr_access ((__write_only__, 2, 3)); # else extern int __xpg_strerror_r (int __errnum, char *__buf, size_t __buflen) __THROW __nonnull ((2)) __attr_access ((__write_only__, 2, 3)); # define strerror_r __xpg_strerror_r # endif Is if musl intends its strerror_r() to work like glibc's strerror_r() then there is a bug. Particularly nasty to have functions that only run when an error condition occurs, to themselves cause crashes. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can't measure it, you can't improve it." - Lord Kelvin --Sig_/5A3y8rJ3yzKXxj06Ttye5PX Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAEBCgAdFiEEDImNR/2vUKZZKLG0LmvF3i7oaj4FAmJV5IsACgkQLmvF3i7o aj6ejQ//UO/+/ms5CpWC1FExQkobFnEVf5r4OCZ+xCWg+EKCIvPTw8+9CVzaCY7P nJ3X4RAdzw32MsHlzFiTDZMVajQAUiuQSnMNyM8A+kstWA3vAuE02c/62ghh4iL5 /UT6R0n9IPKj1uRZUCz5scIR4urUqSefs+rnWzGYr8zkh59wMAhNluiz6JR05OIs 8TkaWWLallrEb4DoEj/PmhvRusNV2VFvea+k/kZ0TuXMaLHBRjGjhVc775aioq7T xiBzyMMSPRD/Fd+Ae3jgfGn0n8H5PGQNAy3IZnCKpA2bhJT/vzVWtHr37Tp5TDWs qN+gqJy1GFK3gZEg0CHFRsyM+S+ce8SfwFrGC7mYsZ0Wht8MpCFrsb19Wx4LY9dL 13KOp6fFelYq0JHYbEsp0FsWu8A0C3VMBvm71cusM9v+gfuGTJwEQN5AaYnm4Xyb VR3cq/0t4SNW8KvBmaEJgNnGnKEHADl4ug5neuIqYATVTcAVa9nlYSjPJahwRzBn diCzNnJ1V+akQniYxaIL/76nrLVrUFiBX4+j3OrKwfTLqGnCkOpjI4aeNTtKOnhw NFmpaBQHAYfzrHefY443EV/FhlvDhow5noi2UfY+z9Ol4Sc2Lx2zyT4keD1Y0ZXc CgVUW8OAwPgLfPxf1HtHXJYnIUruKhGEaj+pZXIrXoWBdPxxlFk= =Pgfx -----END PGP SIGNATURE----- --Sig_/5A3y8rJ3yzKXxj06Ttye5PX--