[tirdesh]

Closes #15760

In a UTF-8 locale, expr STRING : REGEX answered "no match" for any pattern without a \(...\) group as soon as STRING held a byte that is not valid UTF-8, even when the pattern matched the valid characters in front of it. So expr "$name" : '/' printed 0 and exited 1 for a name like /etc/x\377, and the usual idiom for refusing input, expr "$x" : 'PATTERN', stopped firing when the string carried one invalid byte anywhere.

find_match ran the regex on a Latin-1 mapping of the bytes in that case. With no capture group it returned "0" whether or not the regex had matched, which is the same value as the no-match path, so that branch could never report a match at all. With a group, the mapping let . match the invalid byte itself, so captures ran past it.

GNU matches nothing against the invalid sequence but matches the valid characters in front of it as usual. Running the regex on the longest valid prefix gives exactly that, so the Latin-1 branch is gone and both cases now share the existing UTF-8 path:

expr '/etc/x\377' : '/'          1       (was 0, exit 1)
expr '../\377' : '\.\./'         3       (was 0, exit 1)
expr 'a/../\377' : '\(.*\)'      a/../   (was empty, exit 1)
expr '\377..' : '.*\(\.\.\)'     empty, exit 1  (unchanged)

These agree with the GNU 9.7 output quoted in the issue. LC_ALL=C is untouched, and test_m6, where the invalid byte comes first and nothing may match, still passes.

I added test_m8 and test_m9 next to the existing multibyte tests. Both fail on main and pass with the change. That module is #[cfg(target_os = "linux")], so it does not run on macOS; I checked the two tests by lifting the gate locally and then put it back, so they are verified but CI on Linux is the first place they run in anger. cargo fmt --check and clippy -D warnings are clean and test_expr passes. Tested on macOS only.