On Wed, Jun 09 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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@xxxxxxxxx/; 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
