This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

            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

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

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]