This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/12782] New: POSIX strerror_r quality of implementation
- From: "eblake at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Wed, 18 May 2011 23:33:37 +0000
- Subject: [Bug libc/12782] New: POSIX strerror_r quality of implementation
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=12782
Summary: POSIX strerror_r quality of implementation
Product: glibc
Version: 2.13
Status: NEW
Severity: normal
Priority: P2
Component: libc
AssignedTo: drepper.fsp@gmail.com
ReportedBy: eblake@redhat.com
Although POSIX permits 'buf' to remain untouched on error, it does not require
this; in fact, it recommends that buf still be populated insofar as possible
for a better quality of implementation (since applications are likely to use
the contents of buffer without checking for errors). Furthermore, this is more
in line with what glibc does for GNU strerror_r (a useful result at all costs,
even if the result had to be truncated):
XSH line 63300:
"Similarly, implementations are encouraged to have strerror_r( ) return
[EINVAL] and put a string like "unknown error" or "error number xxx" in the
buffer pointed to by strerrbuf when the value of errnum is not a valid error
number."
and http://austingroupbugs.net/view.php?id=398:
"Additionally, implementations are encouraged to NUL-terminate strerrbuf
when failing with ERANGE for any size other than buflen of zero."
If you use the example program of
http://sourceware.org/bugzilla/show_bug.cgi?id=12204, then I argue that the
results on glibc should be:
result: failure 22 Unknown error 18446744073709551614
result: failure 34 Pe
rather than Bruno's claim of
result: failure 22 ______
result: failure 34 ______
Additionally, that bug showed prior art of other platforms that (almost) have
this QoI issue resolved according to POSIX recommendations:
FreeBSD 6.4 (albeit buggy for returning EINVAL on 0), AIX 6.1 (albeit buggy for
not returning ERANGE on short buffer), Tru64 5.1 (albeit buggy for wrong return
values).
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.