mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] ✘strerror_r() bug in musl
@ 2022-04-12 20:43 Gary E. Miller
  2022-04-12 20:48 ` alice
                   ` (3 more replies)
  0 siblings, 4 replies; 18+ messages in thread
From: Gary E. Miller @ 2022-04-12 20:43 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 3113 bytes --]

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 >= 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=600 or -D_POSIX_C_SOURCE=200112L
   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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 851 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] ✘strerror_r() bug in musl
  2022-04-12 20:43 [musl] ✘strerror_r() bug in musl Gary E. Miller
@ 2022-04-12 20:48 ` alice
  2022-04-12 21:04   ` Gary E. Miller
  2022-04-12 20:56 ` Alex Xu (Hello71)
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 18+ messages in thread
From: alice @ 2022-04-12 20:48 UTC (permalink / raw)
  To: musl

On Tue Apr 12, 2022 at 10:43 PM CEST, Gary E. Miller wrote:
> 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.
are you sure it was #musl on libera.chat? there has been a lot of
activity since last friday

--
alice

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] ✘strerror_r() bug in musl
  2022-04-12 20:43 [musl] ✘strerror_r() bug in musl Gary E. Miller
  2022-04-12 20:48 ` alice
@ 2022-04-12 20:56 ` Alex Xu (Hello71)
  2022-04-12 21:07   ` Gary E. Miller
  2022-04-12 21:13   ` Gary E. Miller
  2022-04-13  3:44 ` Rich Felker
  2022-04-13 12:24 ` [musl] *strerror_r() " Natanael Copa
  3 siblings, 2 replies; 18+ messages in thread
From: Alex Xu (Hello71) @ 2022-04-12 20:56 UTC (permalink / raw)
  To: Gary E. Miller; +Cc: musl

The issue of GNU-specific strerror_r has been discussed several times on 
the mailing list: https://inbox.vuxu.org/musl/?q=strerror_r. See:

- https://inbox.vuxu.org/musl/20130208185918.GJ20323@brightrain.aerifal.cx/
- https://inbox.vuxu.org/musl/20180805010455.GQ1392@brightrain.aerifal.cx/

and other threads.

Cheers,
Alex.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] ✘strerror_r() bug in musl
  2022-04-12 20:48 ` alice
@ 2022-04-12 21:04   ` Gary E. Miller
  0 siblings, 0 replies; 18+ messages in thread
From: Gary E. Miller @ 2022-04-12 21:04 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

Yo alice!

On Tue, 12 Apr 2022 22:48:08 +0200
"alice" <alice@ayaya.dev> wrote:

> On Tue Apr 12, 2022 at 10:43 PM CEST, Gary E. Miller wrote:
> > 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.  
> are you sure it was #musl on libera.chat? there has been a lot of
> activity since last friday

Whoops, I'm on freenode #musl now.  20 other people in there.  I'll move
over to freenode.

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 851 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] ✘strerror_r() bug in musl
  2022-04-12 20:56 ` Alex Xu (Hello71)
@ 2022-04-12 21:07   ` Gary E. Miller
  2022-04-12 23:16     ` Wolf
  2022-04-12 21:13   ` Gary E. Miller
  1 sibling, 1 reply; 18+ messages in thread
From: Gary E. Miller @ 2022-04-12 21:07 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

Yo Alex!

On Tue, 12 Apr 2022 16:56:20 -0400
"Alex Xu (Hello71)" <alex_y_xu@yahoo.ca> wrote:

> The issue of GNU-specific strerror_r has been discussed several times
> on the mailing list: https://inbox.vuxu.org/musl/?q=strerror_r. See:
> 
> -
> https://inbox.vuxu.org/musl/20130208185918.GJ20323@brightrain.aerifal.cx/
> -
> https://inbox.vuxu.org/musl/20180805010455.GQ1392@brightrain.aerifal.cx/
> 
> and other threads.

Since I don't use, or follow, musl, not surprising I did not know that.

But I carefully read the include file, the source code, and the doc.  None
of those provided a clue.

You can't expect casual users to have followined your online chats.

If you gonna leave the code as is, then fix the doc.  gpsd has struggled
with this bug for years until I tracked it down.

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 851 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] ✘strerror_r() bug in musl
  2022-04-12 20:56 ` Alex Xu (Hello71)
  2022-04-12 21:07   ` Gary E. Miller
@ 2022-04-12 21:13   ` Gary E. Miller
  1 sibling, 0 replies; 18+ messages in thread
From: Gary E. Miller @ 2022-04-12 21:13 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 1716 bytes --]

Yo Alex!

On Tue, 12 Apr 2022 16:56:20 -0400
"Alex Xu (Hello71)" <alex_y_xu@yahoo.ca> wrote:

> The issue of GNU-specific strerror_r has been discussed several times
> on the mailing list: https://inbox.vuxu.org/musl/?q=strerror_r. See:
> 
> -
> https://inbox.vuxu.org/musl/20130208185918.GJ20323@brightrain.aerifal.cx/
> -
> https://inbox.vuxu.org/musl/20180805010455.GQ1392@brightrain.aerifal.cx/
> 
> and other threads.


The one suggests strerror_l(), which is uselsss for obvious reasons:

   strerror_l()
       strerror_l() is like strerror(), but maps errnum to a  locale-dependent
       error  message in the locale specified by locale.  The behavior of str‐
       error_l()  is  undefined  if  locale  is  the  special  locale   object
       LC_GLOBAL_LOCALE or is not a valid locale object handle.

I'm not going to ever use a function that in many (most?) cases has
"behavior... undefined".

gpsd, finally, solved the problem, by creating a configure test for
the unexpected and undocumented behaviour of strerror_r() in musl.

The other trhead says:

    > Is this a bug in musl?

    No, musl explicitly does not suppore the GNU interfaces that conflict
    with standard interfaces by the same name.

After looking all over the musl source and doc, I can strongly assert that
whatever is "explicitly" statad is very, very, hard to find.

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 851 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] ✘strerror_r() bug in musl
  2022-04-12 21:07   ` Gary E. Miller
@ 2022-04-12 23:16     ` Wolf
  2022-04-13  0:15       ` Gary E. Miller
  0 siblings, 1 reply; 18+ messages in thread
From: Wolf @ 2022-04-12 23:16 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

On 2022-04-12 14:07:24 -0700, Gary E. Miller wrote:
> If you gonna leave the code as is, then fix the doc.  gpsd has struggled
> with this bug for years until I tracked it down.

How did you even managed to compile it when the function returned int
instead of char*? Hard to believe the compiler did not complain...

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] ✘strerror_r() bug in musl
  2022-04-12 23:16     ` Wolf
@ 2022-04-13  0:15       ` Gary E. Miller
  0 siblings, 0 replies; 18+ messages in thread
From: Gary E. Miller @ 2022-04-13  0:15 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

Yo Wolf!

On Wed, 13 Apr 2022 01:16:34 +0200
Wolf <wolf@wolfsden.cz> wrote:

> On 2022-04-12 14:07:24 -0700, Gary E. Miller wrote:
> > If you gonna leave the code as is, then fix the doc.  gpsd has
> > struggled with this bug for years until I tracked it down.  
> 
> How did you even managed to compile it when the function returned int
> instead of char*? Hard to believe the compiler did not complain...

It compiles fine, and runs fine, until it crashes.  The return value
was never used, so no warning generated.  The three variants
of strerror_r() differ in more than just their return value.

Yes, I know, sloppy, which is why I'm trying to problems like this one.

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 851 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] ✘strerror_r() bug in musl
  2022-04-12 20:43 [musl] ✘strerror_r() bug in musl Gary E. Miller
  2022-04-12 20:48 ` alice
  2022-04-12 20:56 ` Alex Xu (Hello71)
@ 2022-04-13  3:44 ` Rich Felker
  2022-04-13 12:24 ` [musl] *strerror_r() " Natanael Copa
  3 siblings, 0 replies; 18+ messages in thread
From: Rich Felker @ 2022-04-13  3:44 UTC (permalink / raw)
  To: Gary E. Miller; +Cc: musl

On Tue, Apr 12, 2022 at 01:43:55PM -0700, Gary E. Miller wrote:
> 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).

This is really a deficiency of the documentation. The text that's
there isn't factually wrong but it's in some sense wrong by omission
-- it omits clearly stating that _GNU_SOURCE does not change anything
to behave in ways that conflict with the standards-specified behaviors
(or change the behavior of standards-specified interfaces whatsoever).
It *only* exposes extension interfaces.

In addition to correcting this, the "criteria for exclusion/inclusion"
of extension functionality should really be written up well and placed
in a conspicuous place. At present it's just scattered across mailing
list discussions of various proposed extensions.

And likewise, the specific example of `strerror_r` (note: `basename`
is like this and is already covered) should be mentioned on the wiki
"differences from glibc" page.

> 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.

The code should not even compile if it's using the wrong signature.
The GNU version of the function does not guarantee that the string is
stored in the provided buf, so you have to examine the return value,
and assignment/passing of an int where a pointer type is expected is a
constraint violation. By default gcc only treats this as a warning
(-Wint-conversion) but you can and should make it an error via
-Werror=int-conversion since code doing this is unconditionally wrong.

Rich

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] *strerror_r() bug in musl
  2022-04-12 20:43 [musl] ✘strerror_r() bug in musl Gary E. Miller
                   ` (2 preceding siblings ...)
  2022-04-13  3:44 ` Rich Felker
@ 2022-04-13 12:24 ` Natanael Copa
  2022-04-13 14:05   ` Rich Felker
  3 siblings, 1 reply; 18+ messages in thread
From: Natanael Copa @ 2022-04-13 12:24 UTC (permalink / raw)
  To: Gary E. Miller; +Cc: musl

On Tue, 12 Apr 2022 13:43:55 -0700
"Gary E. Miller" <gem@rellim.com> wrote:

> Yo All!

Hi!

> 
> 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).

Well, as other has mentioned. GNU libc has a non-compliant version of
strerror_r.

...
 
> When _GNU_SOURCE is defined with glibc, then strerror_r() returns a char *.

I have met this in multiple places the last decade. The usual way to
fix it is to also check for GNU libc in addition to _GNU_SOURCE.

#if defined (__GLIBC__) && defined (_GNU_SOURCE)
	/* non-standard GLIBC exception */
#else
	/* standard behavior for everything else */
#endif

-nc

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] *strerror_r() bug in musl
  2022-04-13 12:24 ` [musl] *strerror_r() " Natanael Copa
@ 2022-04-13 14:05   ` Rich Felker
  2022-04-13 17:36     ` Gary E. Miller
  0 siblings, 1 reply; 18+ messages in thread
From: Rich Felker @ 2022-04-13 14:05 UTC (permalink / raw)
  To: Natanael Copa; +Cc: Gary E. Miller, musl

On Wed, Apr 13, 2022 at 02:24:32PM +0200, Natanael Copa wrote:
> On Tue, 12 Apr 2022 13:43:55 -0700
> "Gary E. Miller" <gem@rellim.com> wrote:
> 
> > Yo All!
> 
> Hi!
> 
> > 
> > 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).
> 
> Well, as other has mentioned. GNU libc has a non-compliant version of
> strerror_r.
> 
> ....
>  
> > When _GNU_SOURCE is defined with glibc, then strerror_r() returns a char *.
> 
> I have met this in multiple places the last decade. The usual way to
> fix it is to also check for GNU libc in addition to _GNU_SOURCE.
> 
> #if defined (__GLIBC__) && defined (_GNU_SOURCE)
> 	/* non-standard GLIBC exception */
> #else
> 	/* standard behavior for everything else */
> #endif

That, or probe for the signature with a configure-style check and use
the result of that, as in

#ifdef HAVE_GNU_STRERROR_R
// handle the GNU version
#else
// code written to the standard
#endif

or, even better, wrapping strerror_r in a translation unit that begins
with

#undef _GNU_SOURCE
#define _POSIX_C_SOURCE 200809L

or similar so that you always get the standard one, and calling your
wrapper instead.

Rich

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] *strerror_r() bug in musl
  2022-04-13 14:05   ` Rich Felker
@ 2022-04-13 17:36     ` Gary E. Miller
  2022-04-13 20:38       ` Rich Felker
  0 siblings, 1 reply; 18+ messages in thread
From: Gary E. Miller @ 2022-04-13 17:36 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 2134 bytes --]

Yo Rich!

On Wed, 13 Apr 2022 10:05:33 -0400
Rich Felker <dalias@libc.org> wrote:

> > > When _GNU_SOURCE is defined with glibc, then strerror_r() returns
> > > a char *.  
> > 
> > I have met this in multiple places the last decade. The usual way to
> > fix it is to also check for GNU libc in addition to _GNU_SOURCE.
> > 
> > #if defined (__GLIBC__) && defined (_GNU_SOURCE)
> > 	/* non-standard GLIBC exception */
> > #else
> > 	/* standard behavior for everything else */
> > #endif  
> 
> That, or probe for the signature with a configure-style check and use
> the result of that, as in
> 
> #ifdef HAVE_GNU_STRERROR_R
> // handle the GNU version
> #else
> // code written to the standard
> #endif

gpsd runs on a huge variety of hardware and software.  We used to have
rats nests of #ifdef's as suggested above.  But that only works when
your library code actually follows your documentation, and our dev
actually read and understood your documentation.

Since you doc fails to mention this "quirk", it is not possible to
forsee this issue before debugging the rare crash.

Now consider that gpsd supports well over 100 targets, back to POSIX
2001. glibc has a long history of changes around strerror_r(), and gpsd
has to support each one.  Then there are all the other libc.  That is a
lot of doc to check.  And a lot of #ifdeff version chacks.

OBTW: did I mention musl does not appear to have any #defines to
specify its current version?  Or even that it is musl?  Or did I
miss something else in the doc?

So you expect me to use the glibc #defines, because musl lacks them.

Not practical at scale.

gpsd prefers to check at configure time for all the known library calls
that are "quirky".  So, what I did was add, yet another, configure time
tesst


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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 851 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] *strerror_r() bug in musl
  2022-04-13 17:36     ` Gary E. Miller
@ 2022-04-13 20:38       ` Rich Felker
  2022-04-13 21:16         ` Gary E. Miller
  0 siblings, 1 reply; 18+ messages in thread
From: Rich Felker @ 2022-04-13 20:38 UTC (permalink / raw)
  To: Gary E. Miller; +Cc: musl

On Wed, Apr 13, 2022 at 10:36:51AM -0700, Gary E. Miller wrote:
> Yo Rich!
> 
> On Wed, 13 Apr 2022 10:05:33 -0400
> Rich Felker <dalias@libc.org> wrote:
> 
> > > > When _GNU_SOURCE is defined with glibc, then strerror_r() returns
> > > > a char *.  
> > > 
> > > I have met this in multiple places the last decade. The usual way to
> > > fix it is to also check for GNU libc in addition to _GNU_SOURCE.
> > > 
> > > #if defined (__GLIBC__) && defined (_GNU_SOURCE)
> > > 	/* non-standard GLIBC exception */
> > > #else
> > > 	/* standard behavior for everything else */
> > > #endif  
> > 
> > That, or probe for the signature with a configure-style check and use
> > the result of that, as in
> > 
> > #ifdef HAVE_GNU_STRERROR_R
> > // handle the GNU version
> > #else
> > // code written to the standard
> > #endif
> 
> gpsd runs on a huge variety of hardware and software.  We used to have
> rats nests of #ifdef's as suggested above.  But that only works when
> your library code actually follows your documentation, and our dev
> actually read and understood your documentation.
> 
> Since you doc fails to mention this "quirk", it is not possible to
> forsee this issue before debugging the rare crash.

Our docs say we aim to conform to ISO C and POSIX. The alternate glibc
strerror_r does not conform to POSIX and therefore we don't do it.
This isn't musl being weird, it's glibc being weird. I agree it would
be helpful to highlight this difference though. We have material on
the wiki covering a bunch of differences from glibc, but somehow this
was overlooked:

https://wiki.musl-libc.org/functional-differences-from-glibc.html

In general, none of these affect software which is not making
non-portable glibc-specific assumptions.

> Now consider that gpsd supports well over 100 targets, back to POSIX
> 2001. glibc has a long history of changes around strerror_r(), and gpsd
> has to support each one.  Then there are all the other libc.  That is a
> lot of doc to check.  And a lot of #ifdeff version chacks.
> 
> OBTW: did I mention musl does not appear to have any #defines to
> specify its current version?  Or even that it is musl?  Or did I
> miss something else in the doc?

No, that's intentional. The macros that tell you what to expect are
_POSIX_VERSION and others from unistd.h. Attempting to hard-code
asssumptions about musl is explicitly unsupported usage. You have to
either detect or just assume standard behavior. It's covered in the
FAQ:

https://wiki.musl-libc.org/faq.html

> So you expect me to use the glibc #defines, because musl lacks them.

No, I expect you not to assume non-conforming glibc behavior on
platforms that aren't glibc. The same would apply on any of the BSDs.

Rich

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] *strerror_r() bug in musl
  2022-04-13 20:38       ` Rich Felker
@ 2022-04-13 21:16         ` Gary E. Miller
  2022-04-13 22:27           ` Rich Felker
  0 siblings, 1 reply; 18+ messages in thread
From: Gary E. Miller @ 2022-04-13 21:16 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 4417 bytes --]

Yo Rich!

On Wed, 13 Apr 2022 16:38:35 -0400
Rich Felker <dalias@libc.org> wrote:

> On Wed, Apr 13, 2022 at 10:36:51AM -0700, Gary E. Miller wrote:
> > Yo Rich!
> > 
> > On Wed, 13 Apr 2022 10:05:33 -0400
> > Rich Felker <dalias@libc.org> wrote:
> >   
> > > > > When _GNU_SOURCE is defined with glibc, then strerror_r()
> > > > > returns a char *.    
> > > > 
> > > > I have met this in multiple places the last decade. The usual
> > > > way to fix it is to also check for GNU libc in addition to
> > > > _GNU_SOURCE.
> > > > 
> > > > #if defined (__GLIBC__) && defined (_GNU_SOURCE)
> > > > 	/* non-standard GLIBC exception */
> > > > #else
> > > > 	/* standard behavior for everything else */
> > > > #endif    
> > > 
> > > That, or probe for the signature with a configure-style check and
> > > use the result of that, as in
> > > 
> > > #ifdef HAVE_GNU_STRERROR_R
> > > // handle the GNU version
> > > #else
> > > // code written to the standard
> > > #endif  
> > 
> > gpsd runs on a huge variety of hardware and software.  We used to
> > have rats nests of #ifdef's as suggested above.  But that only
> > works when your library code actually follows your documentation,
> > and our dev actually read and understood your documentation.
> > 
> > Since you doc fails to mention this "quirk", it is not possible to
> > forsee this issue before debugging the rare crash.  
> 
> Our docs say we aim to conform to ISO C and POSIX. The alternate glibc
> strerror_r does not conform to POSIX and therefore we don't do it.

The musl docs also say you conform to FNU_SOURCE.

Two incompatible statements.

> This isn't musl being weird, it's glibc being weird.

Agreed.  musl is insufficiently documented, and glibc is seird.  Although
to be fair, they invented strerror_r() first, and POSIX munged the copy.

> I agree it would
> be helpful to highlight this difference though. We have material on
> the wiki covering a bunch of differences from glibc, but somehow this
> was overlooked:
> https://wiki.musl-libc.org/functional-differences-from-glibc.html

Since it fails to mention strerror() or strerror_r(), it will never how
up as a result of an internet search.  Easy to fix.   For you, not me.

May I suggest a more obvious place as well:

https://musl.libc.org/doc/1.1.24/manual.html

It currently says:

    _GNU_SOURCE (or _ALL_SOURCE)

    Adds everything above, plus interfaces modeled after GNU libc
    extensions and interfaces for making use of Linux-specific features.

Change that to add:

    Except wher the GNU extensions conflict with POSIX.

And link to the wiki on glibc

> In general, none of these affect software which is not making
> non-portable glibc-specific assumptions.

Afer reading your doc, I thought that was the case for gpsd.

The two fixes above should be a big improvement.

> > OBTW: did I mention musl does not appear to have any #defines to
> > specify its current version?  Or even that it is musl?  Or did I
> > miss something else in the doc?  
> 
> No, that's intentional. The macros that tell you what to expect are
> _POSIX_VERSION and others from unistd.h. Attempting to hard-code
> asssumptions about musl is explicitly unsupported usage. You have to
> either detect or just assume standard behavior. It's covered in the
> FAQ:

And yet, I'm supposed to check the GNU feature macros?  So their defines
are good?  But musl not having the equivalent is good?

Get your story straight please.

But, as I have said before, gpsd does prefer not to use feature #defines
either.  Because they are a mess.  One that includes musl.

> > So you expect me to use the glibc #defines, because musl lacks
> > them.  
> 
> No, I expect you not to assume non-conforming glibc behavior on
> platforms that aren't glibc. The same would apply on any of the BSDs.

No assumptions were made, except that your doc meant what it appeared to
say.  We all agree that it does not mean what it appears to say.

Easy to fix, I leave it to you folks to do so.

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 851 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] *strerror_r() bug in musl
  2022-04-13 21:16         ` Gary E. Miller
@ 2022-04-13 22:27           ` Rich Felker
  2022-04-13 22:43             ` Gary E. Miller
  0 siblings, 1 reply; 18+ messages in thread
From: Rich Felker @ 2022-04-13 22:27 UTC (permalink / raw)
  To: Gary E. Miller; +Cc: musl

On Wed, Apr 13, 2022 at 02:16:52PM -0700, Gary E. Miller wrote:
> Yo Rich!
> 
> On Wed, 13 Apr 2022 16:38:35 -0400
> Rich Felker <dalias@libc.org> wrote:
> 
> > On Wed, Apr 13, 2022 at 10:36:51AM -0700, Gary E. Miller wrote:
> > > Yo Rich!
> > > 
> > > On Wed, 13 Apr 2022 10:05:33 -0400
> > > Rich Felker <dalias@libc.org> wrote:
> > >   
> > > > > > When _GNU_SOURCE is defined with glibc, then strerror_r()
> > > > > > returns a char *.    
> > > > > 
> > > > > I have met this in multiple places the last decade. The usual
> > > > > way to fix it is to also check for GNU libc in addition to
> > > > > _GNU_SOURCE.
> > > > > 
> > > > > #if defined (__GLIBC__) && defined (_GNU_SOURCE)
> > > > > 	/* non-standard GLIBC exception */
> > > > > #else
> > > > > 	/* standard behavior for everything else */
> > > > > #endif    
> > > > 
> > > > That, or probe for the signature with a configure-style check and
> > > > use the result of that, as in
> > > > 
> > > > #ifdef HAVE_GNU_STRERROR_R
> > > > // handle the GNU version
> > > > #else
> > > > // code written to the standard
> > > > #endif  
> > > 
> > > gpsd runs on a huge variety of hardware and software.  We used to
> > > have rats nests of #ifdef's as suggested above.  But that only
> > > works when your library code actually follows your documentation,
> > > and our dev actually read and understood your documentation.
> > > 
> > > Since you doc fails to mention this "quirk", it is not possible to
> > > forsee this issue before debugging the rare crash.  
> > 
> > Our docs say we aim to conform to ISO C and POSIX. The alternate glibc
> > strerror_r does not conform to POSIX and therefore we don't do it.
> 
> The musl docs also say you conform to FNU_SOURCE.

No it does not, and I'm not even sure what "conform to" would mean
here. The Conformance section in the Introduction covers what musl
attempts to conform to, The Library Interfaces section (where the
current manual ends) reiterates that:

"For all interfaces provided by musl that are specified by standards
to which musl aims for conformance, the relevant standards documents
are the official documentation."

The manual does say that _GNU_SOURCE exposes additional extension
interfaces. Not that it works like in glibc and changes the behavior
of standard interfaces. You read that into it. I agree reading that
into it is an easy misreading and that's why I want to make it more
clear.

> Two incompatible statements.
> 
> > This isn't musl being weird, it's glibc being weird.
> 
> Agreed.  musl is insufficiently documented, and glibc is seird.  Although
> to be fair, they invented strerror_r() first, and POSIX munged the copy.
> 
> > I agree it would
> > be helpful to highlight this difference though. We have material on
> > the wiki covering a bunch of differences from glibc, but somehow this
> > was overlooked:
> > https://wiki.musl-libc.org/functional-differences-from-glibc.html
> 
> Since it fails to mention strerror() or strerror_r(), it will never how
> up as a result of an internet search.  Easy to fix.   For you, not me.
> 
> May I suggest a more obvious place as well:
> 
> https://musl.libc.org/doc/1.1.24/manual.html
> 
> It currently says:
> 
>     _GNU_SOURCE (or _ALL_SOURCE)
> 
>     Adds everything above, plus interfaces modeled after GNU libc
>     extensions and interfaces for making use of Linux-specific features.
> 
> Change that to add:
> 
>     Except wher the GNU extensions conflict with POSIX.

Something like that. I would say that we should just be explicit that
this is about exposing additional interfaces only and does not change
the behavior of any standard interface. It's not an exception to
what's written before it. The statement before it is already accurate.
So, at the end of the bulleted list, something like:

"As interpreted by musl, feature test macros only control what
interfaces are exposed. They do not alter the behavior of any function
or change the definition of any type. In particular, `_GNU_SOURCE`
does not cause the signatures or behaviors of functions to change
where GNU libc deviated from the requirements of the standards."

> And link to the wiki on glibc
> 
> > In general, none of these affect software which is not making
> > non-portable glibc-specific assumptions.
> 
> Afer reading your doc, I thought that was the case for gpsd.
> 
> The two fixes above should be a big improvement.
> 
> > > OBTW: did I mention musl does not appear to have any #defines to
> > > specify its current version?  Or even that it is musl?  Or did I
> > > miss something else in the doc?  
> > 
> > No, that's intentional. The macros that tell you what to expect are
> > _POSIX_VERSION and others from unistd.h. Attempting to hard-code
> > asssumptions about musl is explicitly unsupported usage. You have to
> > either detect or just assume standard behavior. It's covered in the
> > FAQ:
> 
> And yet, I'm supposed to check the GNU feature macros?  So their defines
> are good?  But musl not having the equivalent is good?

If you're using __GLIBC__ to work around an intentional glibc
nonconformance issue, that's reasonable usage of it and part of the
way they intend for you to be able to use it.

> Get your story straight please.

I don't see where it's inconsistent.

- Using standard macros provided by the implementation that describe
  interfaces available: good.

- Providing macros that identify an implementation by name and version
  and expecting applications to hard-code knowledge about that
  implementation: bad.

- Doing the best you can do with what glibc gave you: okay.

Rich

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] *strerror_r() bug in musl
  2022-04-13 22:27           ` Rich Felker
@ 2022-04-13 22:43             ` Gary E. Miller
  2022-04-13 22:58               ` Rich Felker
  0 siblings, 1 reply; 18+ messages in thread
From: Gary E. Miller @ 2022-04-13 22:43 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 3408 bytes --]

Yo Rich!

On Wed, 13 Apr 2022 18:27:58 -0400
Rich Felker <dalias@libc.org> wrote:

> > The musl docs also say you conform to FNU_SOURCE.  
> 
> No it does not, and I'm not even sure what "conform to" would mean
> here. The Conformance section in the Introduction covers what musl
> attempts to conform to, The Library Interfaces section (where the
> current manual ends) reiterates that:
> 
> "For all interfaces provided by musl that are specified by standards
> to which musl aims for conformance, the relevant standards documents
> are the official documentation."
> 
> The manual does say that _GNU_SOURCE exposes additional extension
> interfaces. Not that it works like in glibc and changes the behavior
> of standard interfaces. You read that into it. I agree reading that
> into it is an easy misreading and that's why I want to make it more
> clear.

Can we agree it is very misleading and needs to be improved?

> > Change that to add:
> > 
> >     Except wher the GNU extensions conflict with POSIX.  
> 
> Something like that. I would say that we should just be explicit that
> this is about exposing additional interfaces only and does not change
> the behavior of any standard interface. It's not an exception to
> what's written before it. The statement before it is already accurate.

Accurate, but misleading to the casual observer.

> So, at the end of the bulleted list, something like:
> 
> "As interpreted by musl, feature test macros only control what
> interfaces are exposed. They do not alter the behavior of any function
> or change the definition of any type. In particular, `_GNU_SOURCE`
> does not cause the signatures or behaviors of functions to change
> where GNU libc deviated from the requirements of the standards."

Works for me.  Thank you.

> > And yet, I'm supposed to check the GNU feature macros?  So their
> > defines are good?  But musl not having the equivalent is good?  
> 
> If you're using __GLIBC__ to work around an intentional glibc
> nonconformance issue, that's reasonable usage of it and part of the
> way they intend for you to be able to use it.

So you intend for me to use __GLIBC__, for something I'm not sure
about, when __GLIBC__ is not part of your package or defined in your
doc?

I'll stick to direct configure tests.

> > Get your story straight please.  
> 
> I don't see where it's inconsistent.
> 
> - Using standard macros provided by the implementation that describe
>   interfaces available: good.

Except, musl does not provide any?  Or did I miss something?

On second thought, don't bother, I'll stick to direct configure tests.

> - Providing macros that identify an implementation by name and version
>   and expecting applications to hard-code knowledge about that
>   implementation: bad.

I look forward to your glibc bug report on their implementing that
badness. Let's bet on how long before they take that advice?

I'll stick to direct configure tests.

> - Doing the best you can do with what glibc gave you: okay.

Always.

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 851 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] *strerror_r() bug in musl
  2022-04-13 22:43             ` Gary E. Miller
@ 2022-04-13 22:58               ` Rich Felker
  2022-04-13 23:07                 ` Gary E. Miller
  0 siblings, 1 reply; 18+ messages in thread
From: Rich Felker @ 2022-04-13 22:58 UTC (permalink / raw)
  To: Gary E. Miller; +Cc: musl

On Wed, Apr 13, 2022 at 03:43:14PM -0700, Gary E. Miller wrote:
> > > And yet, I'm supposed to check the GNU feature macros?  So their
> > > defines are good?  But musl not having the equivalent is good?  
> > 
> > If you're using __GLIBC__ to work around an intentional glibc
> > nonconformance issue, that's reasonable usage of it and part of the
> > way they intend for you to be able to use it.
> 
> So you intend for me to use __GLIBC__, for something I'm not sure
> about, when __GLIBC__ is not part of your package or defined in your
> doc?

It's not part of our documentation because it has nothing to do with
musl. As far as I can tell, you're only perceiving it as being
"something about musl" because glibc is the frame of reference you're
used to.

> I'll stick to direct configure tests.
> 
> > > Get your story straight please.  
> > 
> > I don't see where it's inconsistent.
> > 
> > - Using standard macros provided by the implementation that describe
> >   interfaces available: good.
> 
> Except, musl does not provide any?  Or did I miss something?

The macros from unistd.h declare conformance to the standards and
which option groups are provided.

There is a proposal for extending this system with information about
extensions that aren't standardized, that was discussed on the
libc-coord mailing list, but it never really moved forward.

> On second thought, don't bother, I'll stick to direct configure tests.

This is a choice I fully support.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [musl] *strerror_r() bug in musl
  2022-04-13 22:58               ` Rich Felker
@ 2022-04-13 23:07                 ` Gary E. Miller
  0 siblings, 0 replies; 18+ messages in thread
From: Gary E. Miller @ 2022-04-13 23:07 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]

Yo Rich!

On Wed, 13 Apr 2022 18:58:43 -0400
Rich Felker <dalias@libc.org> wrote:

> On Wed, Apr 13, 2022 at 03:43:14PM -0700, Gary E. Miller wrote:
> > > > And yet, I'm supposed to check the GNU feature macros?  So their
> > > > defines are good?  But musl not having the equivalent is good?
> > > >   
> > > 
> > > If you're using __GLIBC__ to work around an intentional glibc
> > > nonconformance issue, that's reasonable usage of it and part of
> > > the way they intend for you to be able to use it.  
> > 
> > So you intend for me to use __GLIBC__, for something I'm not sure
> > about, when __GLIBC__ is not part of your package or defined in your
> > doc?  
> 
> It's not part of our documentation because it has nothing to do with
> musl. As far as I can tell, you're only perceiving it as being
> "something about musl" because glibc is the frame of reference you're
> used to.

Uh, I was not the one that brought up __GLIBC__.  I always considered
it out of scope here in musl-land.

> > > - Using standard macros provided by the implementation that
> > > describe interfaces available: good.  
> > 
> > Except, musl does not provide any?  Or did I miss something?  
> 
> The macros from unistd.h declare conformance to the standards and
> which option groups are provided.

I just compared musl unistd.h to glibc unistd.h.  glibc has
many more standards handled than just POSIX.

But don't fix that on my account, I'm just saying...

> There is a proposal for extending this system with information about
> extensions that aren't standardized, that was discussed on the
> libc-coord mailing list, but it never really moved forward.

Then we are now on the same page here.  "unimplemented" but might be
nice.

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 851 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2022-04-13 23:07 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-12 20:43 [musl] ✘strerror_r() bug in musl Gary E. Miller
2022-04-12 20:48 ` alice
2022-04-12 21:04   ` Gary E. Miller
2022-04-12 20:56 ` Alex Xu (Hello71)
2022-04-12 21:07   ` Gary E. Miller
2022-04-12 23:16     ` Wolf
2022-04-13  0:15       ` Gary E. Miller
2022-04-12 21:13   ` Gary E. Miller
2022-04-13  3:44 ` Rich Felker
2022-04-13 12:24 ` [musl] *strerror_r() " Natanael Copa
2022-04-13 14:05   ` Rich Felker
2022-04-13 17:36     ` Gary E. Miller
2022-04-13 20:38       ` Rich Felker
2022-04-13 21:16         ` Gary E. Miller
2022-04-13 22:27           ` Rich Felker
2022-04-13 22:43             ` Gary E. Miller
2022-04-13 22:58               ` Rich Felker
2022-04-13 23:07                 ` Gary E. Miller

Code repositories for project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).