Am 30.11.19 um 19:04 schrieb Junio C Hamano: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx> > writes: > >> * We now assign errno only when the call to CreateProcessW() failed. > > Meaning the global variable 'errno' is left as it was (instead of > getting cleared) when a system call succeeds? That I think is the > correct behaviour people who use the variable expect. I hope you mean people who read the code. You cannot possibly mean developers who expect that the run-command API keeps errno unchanged if the calls were successful. I'm pretty sure they do not provide such a guarantee. > >> * For good measure, we teach the err_win_to_posix() function to translate >> ERROR_SUCCESS into the errno value 0. > > So, I am not sure if this is a good idea---who are the callers of > this function and why do they call it? I would imagine that a > caller who makes a system call, upon seeing a failure from the > system call, calls this helper with the Windows error code it > received from the system call so that errno can be updated with a > POSIXy value. If my imagination is correct, such a caller should > not be assigning anything to errno if the underlying system call > succeeds, i.e. returns ERROR_SUCCESS. So a better solution might > be for the function to BUG() when fed ERROR_SUCCESS to point fingers > at the caller, no? Just like on POSIX the value of errno is indeterminate after a successful system call, the value of GetLastError() indeterminate after a successful Windows API call. Therefore, the err_win_to_posix() would not be able to point at a bogus caller reliably. For this reason, let's consider the function as a simple error code translator, and then translating ERROR_SUCCESS to 0 (or is there ESUCCESS?) makes total sense. -- Hannes
