On Thu, May 26 2022, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> I don't think we should do it like that and keep it a BUG() not to call >> BUG_if_bug() when we hit exit(), because e.g. in the case of >> parse-options.c once we have the a bad "struct options" we don't want to >> continue, as we might segfault, or have other bad behavior etc. So we'd >> like to BUG() out as soon as possible. > > Oh, there is no question about that. When we detect that the > program is in an inconsistent and unexpected state, we would want to > bug out instead of continuing at some point, and that is why we would > want to have BUG_if_bug(), or exit_if_called_bug(), as I called in > the message you are reponding to. > > What I am getting at is that the code often or usually calls > BUG_if_bug() is not a reason to require it to be called, especially > if there are conditional calls to bug() near the end of the program. > Imagine a program, after finishing to respond to the end-user > request, before the end of the program, performing some self sanity > checks with a series of "if (condition) bug()", and there is no more > thing that needs to be done other than exiting after such check. I > would have added such a call to sanity_check_refcnt() at the end of > "git blame", for example, if the facility existed. But you wouldn't want to just stick BUG_if_bug() at the end of those sanity checks? I suppose I can drop the paranoia of requiring it, but since all existing callers want to act that way, and I couldn't imagine a case where you didn't want that I made it act that way.
