On 05/21/2011 11:45 AM, Bruno Haible wrote: > 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?
I plan to work around that, by checking whether strlen(msg) < buflen - 1, and if not, use a second iteration with a larger buffer to prove whether truncation occurred. It's certainly on my list of things to fix before declaring strerror_r complete. >> 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. Yep, and since Uli fixed __xpg_strerror_r in glibc.git, I now have a reason to reject older glibc __xpg_strerror_r versions if they don't do everything nicely. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
