Re: [PATCH 4/4] usage.c: add a non-fatal bug() function to go with BUG()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ævar Arnfjörð Bjarmason  <avarab@xxxxxxxxx> writes:

> Add a bug() function that works like error() except the message is
> prefixed with "bug:" instead of "error:".
>
> The reason this is needed is for e.g. the fsck code. If we encounter
> what we'd consider a BUG() in the middle of fsck traversal we'd still
> like to try as hard as possible to go past that object and complete
> the fsck, instead of hard dying. A follow-up commit will introduce
> such a use in object-file.c.

Reading the description above, i.e. "to go past that object", the
assumed use case seems to be to deal with a data error, not a
program bug (which is where we use BUG()---e.g. one helper function
in the fsck code detected that the caller wasn't careful enough to
vet the data it has and called it with incoherent data).  If we find
a tree entry whose mode bits implies that the object recorded in the
entry ought to be a blob, and later find out that the object turns
out to be a tree, that is a corrupt repository and the code that
detected is not buggy (and we shouldn't use BUG(), of course).

So, ... I am skeptical.  If the code is prepared to handle breakage,
we would not want to die, but then I am not sure why it has to be
different from error().




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux