[Bug general/21010] New: Incompatible with MUSL libc: strerror_r

["luizluca at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21010

            Bug ID: 21010
           Summary: Incompatible with MUSL libc: strerror_r
           Product: elfutils
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: general
          Assignee: unassigned at sourceware dot org
          Reporter: luizluca at gmail dot com
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

>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;
     case OTHER_ERROR (LIBELF):
       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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.