Re: strerror_r questions

[Corinna Vinschen <vinschen at redhat dot com>]

On Feb  5 12:48, Eric Blake wrote:
> Right now, newlib's strerror_r matches neither POSIX nor glibc.
> 
> POSIX requires that it returns int, but newlib always returns the buf
> argument.
> 
> glibc's interface is documented as always returning a NUL-terminated
> string, which may or may not be buf, but newlib uses strncpy which may
> result in an unterminated string.
> 
> So, the question is whether we should fix strerror_r to comply with
> POSIX or to comply with glibc (or even provide both interfaces; glibc
> provides __xpg_strerror_r for the POSIX interface, then uses feature
> test macros to decide whether strerror_r redirects to the POSIX version).
> 
> Furthermore, POSIX recommends, but not requires, that strerror_r
> populate buf with "unknown error xxx" while returning EINVAL for
> out-of-range values, as well as populating as much as buf as possible
> while returning ERANGE when truncation occurs.
> 
> Thoughts on what approach newlib should use before I submit a patch?

First of all, the existing implementation follows glibc's lead, so
it should stick to the API but the behavior should be fixed.

Other than that, the Linux approach would work best.  Provide both
interfaces and use test macros.  Fortunately they are documented in the
man page:

  The XSI-compliant version of strerror_r() is provided if:
  (_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE
  Otherwise, the GNU-specific version is provided.

Ideally we don't define _GNU_SOURCE by default, so this should result in
getting the POSIX version by default.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat