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

Re: [musl] Re: Regression: git no longer works with musl libc's regex impl

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Oct 5, 2016, 11:17 UTC
Message-ID
<alpine.DEB.2.20.1610051250080.35196@virtualbox>
In-Reply-To
<20161004173926.GA19318@brightrain.aerifal.cx>
Hi Rich,
On Tue, 4 Oct 2016, Rich Felker wrote:
Show 8 quoted lines
> On Tue, Oct 04, 2016 at 06:08:33PM +0200, Johannes Schindelin wrote:
>
> > And lastly, the best alternative would be to teach musl about
> > REG_STARTEND, as it is rather useful a feature.
> 
> Maybe, but it seems fundamentally costly to support -- it's extra
> state in the inner loops that imposes costly spill/reload on archs
> with too few registers (x86).
It is true that it could cause that.

I had a brief look at the source code (you use backtracking... hopefully nobody uses musl to parse regular expressions from untrusted, or inexperienced, sources [*1*]), and it seems that the regex code might spill unnecessarily already (I see, for example, that the reg_notbol, reg_noteol and reg_newline flags all use up complete int registers, not merely bits of a single one).

It seems, specifically, that the *match_end_ofs parameter of the two regexec backends is always set to point to eo, which is so far not initialized. You could initialize it to -1 and set it to pmatch[0].rm_eo if the REG_STARTEND flag is set. The GET_NEXT_WCHAR() macro would then need to test something like

	if (str_byte >= string + *match_end_ofs) {
		ret = REG_NOMATCH; goto error_exit;
	}

This does not handle non-zero pmatch[0].rm_so, though. I would probably try to pass another input parameter for that, but I have not verified yet that a "^" would be handled properly (if pmatch[0].rm_so > 0 and REG_STARTEND is set, "^" should *not* match).

> I'll look at doing this when we overhaul/replace the regex
> implementation, and I'm happy to do some performance-regression tests
> for adding it now if someone has a simple patch (as was mentioned on the
> musl list).
I'd be interested to be kept in the loop, if you do not mind Cc:ing me.

Ciao, Johannes

Footnote *1*: http://stackstatus.net/post/147710624694/outage-postmortem-july-20-2016

Previous: Rich FelkerNext: Szabolcs Nagy
Message 9 of 28 in “Regression: git no longer works with musl libc's regex impl”
  1. Rich FelkerOct 4, 2016
  2. Jeff KingOct 4, 2016
  3. Rich FelkerOct 4, 2016
  4. Johannes SchindelinOct 4, 2016
  5. Rich FelkerOct 4, 2016
  6. Johannes SchindelinOct 4, 2016
  7. Ray DonnellyOct 4, 2016
  8. Rich FelkerOct 4, 2016
  9. Johannes SchindelinOct 5, 2016
  10. Szabolcs NagyOct 5, 2016
  11. Rich FelkerOct 5, 2016
  12. James BOct 4, 2016
  13. Rich FelkerOct 4, 2016
  14. Junio C HamanoOct 4, 2016
  15. Jakub NarębskiOct 5, 2016
  16. Rich FelkerOct 5, 2016
  17. Johannes SchindelinOct 5, 2016
  18. James BOct 5, 2016
  19. Jeff KingOct 5, 2016
  20. Rich FelkerOct 5, 2016
  21. Johannes SchindelinOct 6, 2016
  22. Ævar Arnfjörð BjarmasonOct 6, 2016
  23. Jeff KingOct 6, 2016
  24. Rich FelkerOct 6, 2016
  25. Jeff KingOct 6, 2016
  26. Ramsay JonesOct 6, 2016
  27. Jakub NarębskiOct 7, 2016
  28. Johannes SchindelinOct 4, 2016

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.