On Sat, Dec 28, 2019 at 04:41:42PM +0100, Johannes Sixt wrote:

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?

If you ask me: I think so, yes.
At least the documentation about vsnprintf does not mention that errno is touched at all.
That is the man pages for Linux and Mac OS, or see here:
https://linux.die.net/man/3/vsnprintf

It would make sense to analyze the complete callstack, I think.
Is your problem reproducable ?

Changing the function strbuf_vaddf() strbuf.c seems to be straight forward to me.