Hi Paul, Paul Eggert wrote: > I ran into some problems with GNU sed on NetBSD and > endeavored to fix some of them by altering the mbrtoc32 replacement, > so that in the C locale it always converts bytes with the top > bit set to 0xDFxx, instead of doing it only sometimes.
and in <https://lists.gnu.org/archive/html/sed-devel/2026-09/msg00005.html>: > I also installed another patch or two to try to clean > up the issue where Gnulib replaces mbrtoc32 but does not replace c32rtomb to > match. Not entirely happy with the result, but at least sed passes its tests > now on FreeBSD and NetBSD, though Gnulib itself does not. Maybe c32rtomb > should > be replaced in this case? I'm not happy with the result either: - You found an issue (mbrtoc32 followed by c32rtomb in the "C" locale), but did not propose an enhancement to tests/test-c32rtomb.c (which, so far, does this round-trip check for the ISO C "basic character set" only). - The libunistring CI reports a test failure of test-mbrtoc32-1.sh on macOS, FreeBSD, NetBSD, Solaris 11: FAIL: test-mbrtoc32-1.sh ======================== ../../tests/test-mbrtoc32.c:162: assertion 'wc == (0xDF00 | c)' failed FAIL test-mbrtoc32-1.sh (exit status: 1) I am confused about how to go ahead: - I don't know whether it is useful / correct to have c32rtomb map 0xDF80 -> \x80 at all. Would it help to see how musl libc handles this? Maybe code points in the Private Use Area would be better here than 0xDF80..0xDFFF ? - Partially reverting patches is a mess. When you wrote that you "endeavored to fix some of them", I think it would have been better to propose the patch, to give us opportunity to research the scope of the problem in more depth and to think of alternate solutions. I am inclined to - revert the lib/ and tests/ part of this patch, then: - propose a test suite enhancement to tests/test-c32rtomb.c, then, if you agree that it would help fixing the problem in GNU sed: - work on the implementation. Last time we had such an issue (with c32isprint), I took one or two days to think through the issue, promised to work on an implementation, and completed that within two weeks. Have you been unhappy with how that worked out (with c32isprint)? Bruno
