On 05/24/2011 10:45 AM, Sam Steingold wrote: >> * Eric Blake <roy...@erqung.pbz> [2011-05-24 10:32:16 -0600]: >> >>> I do _not_ want strerror_r. >> >> Why not? > > because I copy away the strerror return value right away.
Are you multi-threaded? Then you are suffering from a data race. Are you single threaded? Then you shouldn't care if strerror had to use strerror_r under the hood for its implementation (that's how glibc does it), but you do have a (minor) point that configure is needlessly larger in checking for strerror_r compliance. Yes, strerror() is an easier-to-use interface than sterror_r, but it is _only_ safe in single-threaded programs. Assuming you are single-threaded, your complaint is now: why does gnulib take two files to implement sterror where it used to take one? And the answer is because when gnulib only used one file (that is, strerror.c provided the gnulib replacement strings), then gnulib's perror and strerror_r modules were not standards-compliant, whether or not you used them. Yes, we could make strerror.c and strerror_r.c both implement the gnulib replacement strings, but that adds bulk. So about the only other thing we can do is make both strerror.c and strerror_r.c call into a third file that implements the gnulib replacement strings, and thus make it so that strerror no longer directly depends on strerror_r.c; patches welcome. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
