Re: strerror_r and POSIX

[Bruno Haible]

Hi Eric,

> > I would find these enhancements to the strerror_r specification useful
> > as well. But I would wait before changing gnulib until the issue has been
> > discussed in the Austin group and glibc has followed suit. If they start
> > to disagree, it's too early for gnulib to provide the modified (proposed)
> > semantics.
> 
> There's two things at stake here.
> 
> One is whether strerror_r _must_ fail with ERANGE on a too-short buffer
> (well, the combination of too-short buffer and out-of-range errnum can
> still fail with EINVAL); right now, POSIX leaves the ERANGE error as
> optional, but http://austingroupbugs.net/view.php?id=398 will require it
> to be mandatory.  Although that bug report has not yet been approved, I
> see no problem in implementing it now

What about the platforms that don't return ERANGE when they truncate?
According to <http://sourceware.org/bugzilla/show_bug.cgi?id=12204> these
are AIX 6.1 and OSF/1 5.1. Are we sure that we override the system's
strerror_r() on these platforms?

> The other is whether strerror_r may modify buf even when returning
> ERANGE or EINVAL.  Right now, POSIX does not forbid this, and in fact,
> it even recommends it in the case of EINVAL.  I took care in
> http://austingroupbugs.net/view.php?id=398 to also add wording
> recommending that buf is also modified in the case of ERANGE to always
> be a NUL-terminated string (except for 0-size buf).  And it is this
> issue that glibc is _not_ doing (hence glibc bug 12782)

OK, the ticket in glibc is now fixed. So even if the Austin group rejects
your proposal, gnulib will be implementing a GNU extension.

Here too, the question: are we replacing strerror_r on all relevant platforms?
According to <http://sourceware.org/bugzilla/show_bug.cgi?id=12204>
it's HP-UX 11.31. Oh yes, we do, because HP-UX 11.31 also has another bug.

Bruno
-- 
In memoriam Alfred Grünberg <http://en.wikipedia.org/wiki/Alfred_Grünberg>