On 05/25/2011 02:59 AM, Simon Josefsson wrote: >> Therefore, I'm afraid that the more portable choice is to consistently >> stick to the standard definition, rather than the GNU definition, even >> if the GNU definition is slightly easier to use. > > Yes. What we'd really like is a dependency scheme that can express > something like "strerror_r-gnu | strerror_r-posix"...
But that _still_ leaves us with the issue of how do you know which signature of strerror_r you are calling? Remember, glibc strerror_r(EACCES,buf,len) leaves buf untouched - you are expected to use the returned pointer; but XPG strerror_r(EACCES,buf,len) returns an int which is almost guaranteed to be fatal if you dereference it as a char*. If glibc were to change GNU strerror_r to _always_ populate buf, in addition to the return string, then you could blindly call either variant of strerror_r and just ignore the return value; the only remaining problem is making sure you provide a large enough buffer for any resulting string, since you no longer have error checking to tell if buf got truncated. I guess it's worth a shot asking Uli if he'll make that change in glibc (since he already changed __xpg_strerror_r to populate buf). >> Since the whole point of strerror_r is to get an error message to be >> worth printing, it's easier to stick with the POSIX recommendations >> that the message be usable regardless of error, even though POSIX (for >> backwards compatibility reasons) chose to permit weaker >> implementations. > > ..although if it comes with the portability hurdles of threads, I'm not > convinced it will be "easier" for everyone in the long run. Which somewhat goes back to my question of whether using the strerror_r in a single-thread program should drag in the lock module, or if it acceptable to conditionally compile in the lock code in strerror_r.c if lock is present but otherwise skip locking, under the assumption that any multi-threaded program is explicitly using locks in addition to strerror_r. Or maybe make a 'strerror_r-posix-simple' that is not thread-safe, which does not depend on 'lock', and 'strerror_r-posix' depends on 'strerror_r-posix-simple' and on 'lock', so that the default module name is thread-safe, and you have to ask for the longer module name if you explicitly don't care about locking but want to use the reentrant interface. Then again, if you are single-threaded, then 'strerror' is easier to use than 'strerror_r'. So I've somewhat convinced myself that things are fine as they are - strerror_r-posix should drag in 'lock', and we don't need a single-threaded variant there. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
