On Wed, Jun 09 2021, Junio C Hamano wrote:

Ævar Arnfjörð Bjarmason  [off-list ref] writes:

quoted

Change various cmd_* functions that claim no return an "int" to use

s/no return/to return/

quoted

"return" instead of exit() to indicate an exit code. These were not
marked with NORETURN,

Up to this point, it is well written.

quoted

and by directly exit()-ing we'll skip the
cleanup git.c would otherwise do (e.g. closing fd's, erroring if we
can't). See run_builtin() in git.c.

But I think this is a hyperbole.  File descritors are closed when we
exit without git.c's help, thank-you-very-much ;-), [...]

Closed yes, but not ", erroring if we can't". That's referring to the
behavior in git.c added in g0f157315a1 (Check for IO errors after
running a command, 2007-06-24) and 0227f9887b (git: Try a bit harder not
to lose errno in stdio, 2007-06-30).

That strictness isn't something you get by default from an exiting C
program, which is why we're explicitly checking and calling die_errno()
in run_builtin().

I wasn't aiming for hyperbole, just accurately describing the
implications of skipping the code we'd skip before this patch.

[...]and if we do
have clean-ups that are truly important, we would have arranged them
to happen in the atexit handler, so it is not a crime for functions
called from the subcommand dispatchers to exit themselves (as long
as they exit sensibly, e.g. without doing nonsense like exit(-1)).

I'm not quite sure what "clean-ups that are truly important" is meant to
get at here. I was just describing the cleanups in git.c that we were
skipping, which aren't implemened as atexit handlers.

But no, those couldn't be done in atexit handlers as they call
die_errno() or BUG(), and both of them want to modify the exit code. The
atexit() handlers cannot modify the exit code (both per the C standard,
and POSIX).

That particular edge was last last discussed on-list in my
https://lore.kernel.org/git/20210202020001.31601-6-avarab@gmail.com/ (local);
when the whole "should SIGPIPE from the pager be ignored" topic came up.

So it's really the opposite of what you're saying. If you have cleanups
that are truly important, i.e. so important that you'd like to notify
the user with a non-zero exit code if they fail, you *don't* want them
in an atexit handler. That won't work.

It nevertheless is a good idea because it encourages good code
hygiene, just like marking with NORETURN if the function must exit.
Selling this change as if it were a correctness fix (i.e. we were
exiting and missed these important clean-ups that the caller wanted
to do after we return) is misleading.

Before this patch:

    $ git ls-tree HEAD | git mktree >/dev/full; echo $?
    0

After:

    $ git ls-tree HEAD | git mktree >/dev/full; echo $?
    fatal: unknown write failure on standard output
    128

So yes, it's a correctness fix, and you can't do that in an atexit
handler, at least not portably.

You might find that if you try it that it works perfectly fine. But
that's because e.g. glibc does non-standard shenanigans to make it work,
but it's not portable behavior. See
e.g. https://wiki.musl-libc.org/functional-differences-from-glibc.html#Re_entrancy_of_exit

That page suggests that glibc's behavior might be an accident, but it's
not. They explicitly support that non-standard behavior of an atexit
handler munging the exit code. See their implementation & comments:
https://github.com/bminor/glibc/blob/master/stdlib/exit.c