In sha1-file.c:read_object_file_extended() we have the following pattern:
errno = 0;
data = read_object(r, repl, type, size);
if (data)
return data;
if (errno && errno != ENOENT)
die_errno(_("failed to read object %s"), oid_to_hex(oid));
That is, it is expected that read_object() does not change the value of
errno in the non-error case. I find it intriguing that we expect a quite
large call graph that is behind read_object() to behave this way.
What if a subordinate callee starts doing
if (some_syscall(...) < 0) {
if (errno == EEXIST) {
/* never mind, that's OK */
...
}
}
Would it be required to reset errno to its previous value in this
failure-is-not-an-error case?
The problem in my Windows build is that one of these subordinate
syscalls is vsnprintf() (as part of a strbuf_add variant, I presume),
and it fails with ERANGE when the buffer is too short. Do I have to
modify the vsnprintf emulation to restore errno?
