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.
