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

Re: [PATCH] userdiff: support regexec(3) with multi-byte support

From
Johannes Sixt <j6t@kdbg.org>
Date
Apr 6, 2023, 22:35 UTC
Message-ID
<7fe0aa93-a764-66b0-5015-2f5fbd3901ab@kdbg.org>
In-Reply-To
<7327ac06-d5da-ec53-543e-78e7729e78bb@web.de>
Am 06.04.23 um 22:19 schrieb René Scharfe:
Show 15 quoted lines
> Since 1819ad327b (grep: fix multibyte regex handling under macOS,
> 2022-08-26) we use the system library for all regular expression
> matching on macOS, not just for git grep.  It supports multi-byte
> strings and rejects invalid multi-byte characters.
> 
> This broke all built-in userdiff word regexes in UTF-8 locales because
> they all include such invalid bytes in expressions that are intended to
> match multi-byte characters without explicit support for that from the
> regex engine.
> 
> "|[^[:space:]]|[\xc0-\xff][\x80-\xbf]+" is added to all built-in word
> regexes to match a single non-space or multi-byte character.  The \xNN
> characters are invalid if interpreted as UTF-8 because they have their
> high bit set, which indicates they are part of a multi-byte character,
> but they are surrounded by single-byte characters.

Perhpas the expression should be "[\xc4\x80-\xf7\xbf\xbf\xbf]+", i.e., sequences of code points U+0080 to U+10FFFF?

> 
> Replace that expression with "|[^[:space:]]" if the regex engine
> supports multi-byte matching, as there is no need to have an explicit
> range for multi-byte characters then.

This is not equivalent. The original treated a sequence of non-ASCII characters as a word. The new version treats each individual non-space character (both ASCII and non-ASCII) as a word.

Show 6 quoted lines
> Additionally the word regex for tex contains the expression
> "[a-zA-Z0-9\x80-\xff]+" with a similarly invalid range.  The best
> replacement with only valid characters that I can come up with is
> "([a-zA-Z0-9]|[^\x01-\x7f])+".  Unlike the original it matches NUL
> characters, though.  Assuming that tex files usually don't contain NUL
> this should be acceptable.
This is acceptable, of course. The replacement range looks sensible.
-- Hannes
Previous: René ScharfeNext: René Scharfe
Message 8 of 13 in “regex compilation error with --color-words”
  1. Eric SunshineMar 29, 2023
  2. Diomidis SpinellisMar 30, 2023
  3. René ScharfeMar 31, 2023
  4. René ScharfeApr 2, 2023
  5. Junio C HamanoApr 3, 2023
  6. René ScharfeApr 3, 2023
  7. userdiff: support regexec(3) with multi-byte supportRené Scharfe, Apr 6, 2023
  8. Johannes SixtApr 6, 2023
  9. René ScharfeApr 7, 2023
  10. Johannes SixtApr 7, 2023
  11. D. Ben KnobleApr 7, 2023
  12. Junio C HamanoApr 7, 2023
  13. Eric SunshineApr 7, 2023

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.