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>
