Bug 21010 - Incompatible with MUSL libc: strerror_r
Summary: Incompatible with MUSL libc: strerror_r
Alias: None
Product: elfutils
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Blocks: 21002
  Show dependency treegraph
Reported: 2016-12-30 21:13 UTC by Luiz Angelo Daros de Luca
Modified: 2021-02-05 14:49 UTC (History)
5 users (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Luiz Angelo Daros de Luca 2016-12-30 21:13:54 UTC
From original bug 21002

- I have to think about that strerror_r replacement. Normally we expect just a static string describing a known errno. But I see we have to handle unknown numbers too. hmmm.

The used behavior is GNU-specific:

       The GNU-specific strerror_r() returns a pointer to a string containing the error message.  This may be either a pointer to a string that the function stores  in  buf,  or  a  pointer  to  some
       (immutable)  static  string (in which case buf is unused).  If the function stores a string in buf, then at most buflen bytes are stored (the string may be truncated if buflen is too small and
       errnum is unknown).  The string always includes a terminating null byte ('\0').

A portable way to solve this is stick to the XSI-compliant behavior (as in the patch).

--- a/libdwfl/dwfl_error.c
+++ b/libdwfl/dwfl_error.c
@@ -140,6 +140,7 @@ __libdwfl_seterrno (Dwfl_Error error)
 const char *
 dwfl_errmsg (int error)
+  static __thread char s[64] = "";
   if (error == 0 || error == -1)
       int last_error = global_error;
@@ -154,7 +155,8 @@ dwfl_errmsg (int error)
   switch (error &~ 0xffff)
     case OTHER_ERROR (ERRNO):
-      return strerror_r (error & 0xffff, "bad", 0);
+      strerror_r (error & 0xffff, s, sizeof(s));
+      return s;
       return elf_errmsg (error & 0xffff);
     case OTHER_ERROR (LIBDW):

However, according to the comments on the original bug, it might be interesting to find a new way to deal with it.
Comment 1 Florian Fainelli 2017-05-22 22:56:56 UTC
strerror_r is marked with __must_check on glibc, and this leads to the following warnings/errors (with Werror):

dwfl_error.c: In function 'dwfl_errmsg':
dwfl_error.c:158:18: error: ignoring return value of 'strerror_r', declared with attribute warn_unused_result [-Werror=unused-result]
       strerror_r (error & 0xffff, s, sizeof(s));
cc1: all warnings being treated as errors
Comment 2 Florian Fainelli 2017-05-22 22:57:31 UTC
(In reply to Florian Fainelli from comment #1)
> strerror_r is marked with __must_check on glibc, and this leads to the
> following warnings/errors (with Werror):

Sorry, not __must_check, but the return value becomes unused here.
Comment 3 Mark Wielaard 2021-02-05 14:49:29 UTC
commit 8db222e36ae777e6aec8c61c616838a86258e99f
Author: Érico Rolim <erico.erc@gmail.com>
Date:   Mon Feb 1 21:16:56 2021 -0300

    libdwfl: use GNU strerror_r only when available.
    Some C libraries don't provide the GNU version of strerror_r, only the
    XSI-compliant one. We use the GNU version when available, since it fits
    the code better, and otherwise use the XSI-compliant one.
    Signed-off-by: Érico Rolim <erico.erc@gmail.com>