Sun Feb 6 09:52:00 GMT 2011
Right now, newlib's strerror_r matches neither POSIX nor glibc.
POSIX requires that it returns int, but newlib always returns the buf
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?
Eric Blake firstname.lastname@example.org +1-801-349-2682
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 619 bytes
Desc: OpenPGP digital signature
More information about the Newlib