Eric Blake wrote: > More accurately: > > The change in strerror_r behavior was in 1.7.8 (which also tried to > introduce __xpg_strerror_r), but a bug in the headers vs. export table > ended up with a link failure for __xpg_strerror_r: > http://cygwin.com/ml/cygwin/2011-03/msg00247.html > > In <= 1.7.7, the result was always buf, and truncation occurred for both > in-range and out-of-range errors. > > In >= 1.7.8, the result for in-range buffers is static and buf is > untouched, and out-of-range errors returns buf with possible truncation.
Thanks for the info. I've updated the comments accordingly. > Yes, that looks good, other than any comment wording tweaks you might want. OK. Committed and pushed. > [Actually, I plan on further enhancing gnulib strerror_r to work around > http://sourceware.org/bugzilla/show_bug.cgi?id=12782, which may cause me > to have to revisit this code at the same time I add in glibc > workarounds, but that can come after your patch] 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. Bruno -- In memoriam Anne Boleyn <http://en.wikipedia.org/wiki/Anne_Boleyn>
