Plato Kiorpelidis <kioplato@xxxxxxxxx> writes: >> And less portable for the invoking process of "git". The invoking >> process used to be able to depend ou getting WEXITSTATUS() from our >> exit status to obtain "1" when we exited with 1; if we start exiting >> with EXIT_FAILURE, there is no guarantee what non-zero value is used. >> >> So, I am not sure if this is a good direction to go in. > > From what I understand, this is a point about why EXIT_FAILURE and EXIT_SUCCESS > are a bad idea in Git's case in general; not specifically in test-tool's case. > The test-tool doesn't use child processes, therefore it doesn't use the macro > WEXITSTATUS. As a result, supposedly, we could use EXIT_FAILURE and EXIT_SUCCESS > constants in this case. However, we don't want to use them in order to stay > consistent throughtout Git's implementation. Is my understanding correct? Yes, it is a bad idea for any tool (not limited to Git) whose documentation does not say "on failure, it exits with non-zero exit status", but signals what kind of failure with different non-zero exit status values. Perhaps the calling test scripts of test-tool may only care about exit status being (or not being) zero, so we could use EXIT_FAILURE vs EXIT_SUCCESS, as long as EXIT_FAILURE does not exit with a value that confuses test_must_fail, but by design, the code that uses EXIT_FAILURE cannot guarantee that---the whole point of EXIT_FAILURE macro is to hide which exact value is used. You are correct to assume that we'd want to avoid using EXIT_FAILURE in test-tool because we do not want to tempt people to copy-and-paste. Thanks.
