Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > 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. It just is one more thing that needs testing. But in any case, that was more or less a tongue-in-cheek suggestion and not a serious counter proposal. Let's drop it now and stop wasting our time. Thanks.
