bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: strerror and perror / strerror_r error messages differ


From: Bruno Haible
Subject: Re: strerror and perror / strerror_r error messages differ
Date: Sat, 03 Sep 2022 01:55:22 +0200

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]