Re: [PATCH] diff: handle negative status in diff_result_code()

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

Jeff King <peff@peff.net> writes:

> Thanks for your report. And I'm impressed you managed to find such an
> ancient bug. :)

Indeed.  Thanks, both.

> Most programs which run a diff (porcelain git-diff, diff-tree, etc) run
> their result through diff_result_code() before presenting it to the user
> as a program return code. That result generally comes from a library
> function like builtin_diff_files(), etc, and may be "-1" if the function
> bailed with an error.
>
>
> There are two problems here:
>
>   - if --exit-code is not in use, then we pass the code along as-is.
>     Even though Unix exit codes are unsigned, this usually works OK
>     because the integer representation, and "-1" ends up as "255". But
>     it's not something we should rely on, and we've tried to avoid it
>     elsewhere. E.g. in 5391e94813 (branch: remove negative exit code,
>     2022-03-29) and 246f0edec0 (execv_dashed_external: stop exiting with
>     negative code, 2017-01-06) and probably others.
>
>   - when --exit-code is in use, we ignore the incoming "status" variable
>     entirely, and rely on the "has_changes" field. But if we saw an
>     error, this field is almost certainly invalid, and means we'd likely
>     just say "no changes", which is completely bogus. Likewise for
>     the "--check" format.

Inspecting some callers of diff_result_code() further finds
curiosities.  wt-status.c for example feeds results form
run_diff_index() and run_diff_files() to the function, neither of
which returns anything other than 0. They die or exit(128)
themselves, though, so they are OK without this fix.
builtin/describe.c is also in the same boat with its use of
run_diff_index().

But of course the presense of such codepaths does not invalidate the
fix in your patch.

> So let's intercept the negative value here and return an appropriate
> code before even considering --exit-code, etc. And while doing so, we
> can swap out the negative value for a more normal exit code.

Good.  As you said, this is not an ungent regression fix, but I'd
prefer to see us look at all the current callers, as I wonder if
there are positive non-zero numbers coming from some callers, and
possibly design how this code should react to such "result" coming
in.

Again, thanks, both.