Re: [PATCH 2/2] A loose object is not corrupt if it cannot be read due to EMFILE

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 [off-list ref] wrote:

quoted

Erik Faye-Lund wrote:

quoted

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