Re: [PATCH v2 04/15] test-dir-iterator: consistently return EXIT_FAILURE or EXIT_SUCCESS

[Junio C Hamano <gitster@pobox.com>]

Plato Kiorpelidis <kioplato@gmail.com> 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.