git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 4/4] line-log: convert an assertion to a full BUG() call

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Aug 6, 2018, 13:14 UTC
Message-ID
<nycvar.QRO.7.76.6.1808061510260.71@tvgsbejvaqbjf.bet>
In-Reply-To
<CAPig+cRrC2mf1uuQ1C4Ue4OMZQbgcxXbJ9AXs0y6RSnUrcm7Dg@mail.gmail.com>
Hi Eric,
On Sun, 5 Aug 2018, Eric Sunshine wrote:
Show 18 quoted lines
> On Sat, Aug 4, 2018 at 6:18 PM Johannes Schindelin via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
> > The assertion in question really indicates a bug, when triggered, so we
> > might just as well use the sanctioned method to report it.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> > diff --git a/line-log.c b/line-log.c
> > @@ -72,7 +72,9 @@ void range_set_append(struct range_set *rs, long a, long b)
> > -       assert(rs->nr == 0 || rs->ranges[rs->nr-1].end <= a);
> > +       if (rs->nr > 0 && rs->ranges[rs->nr-1].end > a)
> > +               BUG("append %ld-%ld, after %ld-%ld?!?", a, b,
> > +                   rs->ranges[rs->nr-1].start, rs->ranges[rs->nr-1].end);
> 
> Although this appears to be a faithful translation of the assert() to
> BUG(), as mentioned by Andrei in his review of 3/4, the existing
> assert() seems to have an off-by-1 error, which means that the "> a"
> here really ought to be ">= a".

I think Andrei's assessment is wrong. The code could not test for that earlier, as it did allow ranges to become "abutting" in the process, by failing to merge them. So the invariant you talked about is more of an invariant for the initial state.

My 3/4 would make that invariant heeded throughout the process.

I am still keen on keeping the invariants straight *without* resorting to dirty tricks like calling sort_and_merge. Calling that function would just make it easier for bugs to hide in this code.

> Given that this file is full of assert()'s, it doesn't necessarily
> make sense to convert only this one, so perhaps the patch should be
> dropped (since I'm guessing you don't want to convert the rest of
> them).

Sure, there are 18 of them, and you're right, I lack the time to convert them.

Ciao, Dscho

Previous: Eric SunshineNext: Eric Sunshine
Message 17 of 20 in “line-log: be more careful when adjusting multiple line ranges”
  1. 0/4 line-log: be more careful when adjusting multiple line rangesJohannes Schindelin via GitGitGadget, Aug 4, 2018
  2. 1/4 line-log: demonstrate a bug with nearly-overlapping rangesJohannes Schindelin via GitGitGadget, Aug 4, 2018
  3. Jonathan NiederAug 5, 2018
  4. Johannes SchindelinAug 6, 2018
  5. Jonathan NiederAug 6, 2018
  6. Jonathan NiederAug 6, 2018
  7. 2/4 line-log: adjust start/end of ranges individuallyJohannes Schindelin via GitGitGadget, Aug 4, 2018
  8. Eric SunshineAug 5, 2018
  9. Eric SunshineAug 5, 2018
  10. Johannes SchindelinAug 6, 2018
  11. 3/4 line-log: optimize ranges by joining them when possibleJohannes Schindelin via GitGitGadget, Aug 4, 2018
  12. Junio C HamanoAug 5, 2018
  13. Andrei RybakAug 5, 2018
  14. Eric SunshineAug 5, 2018
  15. 4/4 line-log: convert an assertion to a full BUG() callJohannes Schindelin via GitGitGadget, Aug 4, 2018
  16. Eric SunshineAug 5, 2018
  17. Johannes SchindelinAug 6, 2018
  18. Eric SunshineAug 7, 2018
  19. Eric SunshineAug 7, 2018
  20. Eric SunshineAug 5, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.