Subject: Re: [PATCH v2] builtins + test helpers: use return instead of exit() in cmd_*

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Wed, 09 Jun 2021 03:54:22 +0200

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

> Ævar Arnfjörð Bjarmason  <[email-masked]> writes:
>
>> Change various cmd_* functions that claim no return an "int" to use
>
> s/no return/to return/
>
>> "return" instead of exit() to indicate an exit code. These were not
>> marked with NORETURN,
>
> Up to this point, it is well written.
>
>> 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/[email-masked]/;
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