Samuel Thibault wrote:
> > The gnulib code made the assumption that strerror_r always returns a
> > thread-safe untruncated string. This assumption is wrong both on glibc/Linux
> > and on glibc/Hurd.
>
> ? IIRC at least as of glibc master, on Linux it does fill the string
> even on error.
Yes, glibc strerror_r fills the string, but gnulib nevertheless cannot
accommodate a result of, say,
"Unknown error -4"
because that might be a truncated variant of
"Unknown error -42"
or
"Unknown error -425"
and gnulib needs to know whether the complete error message would have
been longer than what was returned.
glibc does this for Linux, see glibc/string/_strerror.c:
__snprintf (buf, buflen, "%s%d", _("Unknown error "), errnum);
return buf;
and also does it for Hurd, see glibc/sysdeps/mach/_strerror.c:
__snprintf (buf, buflen, "%s: %d", _("Error in unknown error system: "),
errnum);
return buf;
...
__snprintf (buf, buflen, "%s%s %d", _("Unknown error "),
es->subsystem[sub].subsys_name, errnum);
return buf;
But there's nothing you can do about it: If the caller passes a small
buffer, and you want to return a string that is either of indefinite
lifetime or in the passed buffer, there's no other choice. (Returning a
pointer to a glibc-owned buffer with __thread storage class would not
be good, because it would be overwritten at moments when the application
does not expect it.)
Bruno
