Jeff King <peff@xxxxxxxx> 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.
