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.
