git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org,
	Felipe Contreras <felipe.contreras@gmail.com>,
	Jeff King <peff@peff.net>
Subject: Re: [PATCH v2] builtins + test helpers: use return instead of exit() in cmd_*
Date: Wed, 09 Jun 2021 03:54:22 +0200	[thread overview]
Message-ID: <87im2n3gje.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <xmqqwnr3nc7i.fsf@gitster.g>


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

> Ævar Arnfjörð Bjarmason  <avarab@gmail.com> 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/20210202020001.31601-6-avarab@gmail.com/;
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

  reply	other threads:[~2021-06-09  2:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-07 11:12 [PATCH] " Ævar Arnfjörð Bjarmason
2021-06-07 17:02 ` Felipe Contreras
2021-06-08  6:49 ` Jeff King
2021-06-08 10:53   ` Ævar Arnfjörð Bjarmason
2021-06-10 13:16   ` Phillip Wood
2021-06-10 13:19     ` Ævar Arnfjörð Bjarmason
2021-06-08 10:48 ` [PATCH v2] " Ævar Arnfjörð Bjarmason
2021-06-08 23:55   ` Junio C Hamano
2021-06-09  1:54     ` Ævar Arnfjörð Bjarmason [this message]
2021-06-09  3:38       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87im2n3gje.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --subject='Re: [PATCH v2] builtins + test helpers: use return instead of exit() in cmd_*' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://7fh6tueqddpjyxjmgtdiueylzoqt6pt7hec3pukyptlmohoowvhde4yd.onion/inbox.comp.version-control.git
	nntp://ie5yzdi7fg72h7s4sdcztq5evakq23rdt33mfyfcddc5u3ndnw24ogqd.onion/inbox.comp.version-control.git
	nntp://4uok3hntl7oi7b4uf4rtfwefqeexfzil2w6kgk2jn5z2f764irre7byd.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git