On 2026-09-14 13:23, Bruno Haible wrote:
Paul Eggert wrote:
I seem to have jumped the gun on this one; sorry about that. I did the first
step of your plan by reverting the lib/ and tests/ part of the patch.
OK.
The next step, a test suite enhancement to tests/test-c32rtomb.c, is attached,
based on your added comments
On some platforms, when Gnulib's @code{mbrtoc32} module is used,
in the C locale @code{mbrtoc32} translates bytes in the range 0x80--0xFF
to @code{char32_t} values in the range 0xDF80--0xDFFF,
but when those @code{char32_t} values are given to this function
it fails with @code{EILSEQ} instead of translating them back:
and <https://lists.gnu.org/archive/html/sed-devel/2026-09/msg00005.html>.
Is that what you need for GNU sed?
Yes, the idea is that if mbrtoc32 succeeds in the C locale, it should yield a
char32_t that can be fed back into c32rtomb and get the original byte.
Currently it fails on: glibc, OpenBSD, Cygwin, mingw, MSVC. (Which is a little
more than the platforms from
<https://lists.gnu.org/archive/html/bug-gnulib/2026-08/msg00308.html>.)
The test also fails on NetBSD 11.0 because in the C locale its mbrtoc32 treats
bytes in the range 0x80-0xFF as encoding errors, like glibc does. It seems that
NetBSD 11.0 was the first NetBSD version to support mbrtoc32.
And the test succeeds on FreeBSD 15.1 but I think that may be due to another
bug, where Gnulib's btoc32(0x80) yields 0x80; isn't btoc32(0x80) supposed to
yield 0xDF80 in the C locale, so that we can run c32isprint on the result?
