ERANGE strikes again on my Windows build; RFH

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?