On Thu, Nov 18, 2010 at 07:18:37PM +0100, Erik Faye-Lund wrote: > On Thu, Nov 18, 2010 at 6:29 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > > Erik Faye-Lund wrote: > > > >> I was wondering about the same thing, I don't think this approach is > >> very easy to follow. But either way I think we should make sure > >> opendir/closedir/readdir doesn't mess with errno. > > > > Other platforms and are allowed to (and do) clobber errno in many > > non-error situations, so the main effect would be to work around/hide > > some git bugs. > > I don't think that's the case; K&R (section B1.7) says "In addition, > the integer expression errno (declared in <errno.h>) may contain an > error number that contains information about the most recent error.". > A non-error condition would not be information about the most recent > error. I interpret the use of the word "may" to mean "some functions > does not update errno, so errno could also have information about > older errors" not as "some functions can clear errno", but other might > disagree with me. > > POSIX (which defines opendir) says "No function in this volume of IEEE > Std 1003.1-2001 shall set errno to 0", so I think it's clear cut in > this case. (see > http://www.opengroup.org/onlinepubs/009695399/functions/errno.html for > the full text) > > We also seem to depend quite heavily on errno being preserved on > non-errors some places around in the code. Errno can be clobbered if some subset of the operation in question failed but the operation itself succeeded. For example suppose opendir did a memory allocation that failed, but was able to recover from it and return successfully. Errno might contain ENOMEM at the exit. tl;dr - errno can be clobbered when functions that succeed call functions that fail while progressing. --CJD -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html