Paul Eggert wrote:
> On 2023-07-02 06:33, Bruno Haible wrote:
> > +else if (bytes == (size_t) -3)
> > + bytes = 0;
>
> Why is this sort of thing needed?
I tried to explain it in
https://lists.gnu.org/archive/html/bug-gnulib/2023-06/msg00134.html .
Basical
On 2023-07-02 06:33, Bruno Haible wrote:
+else if (bytes == (size_t) -3)
+ bytes = 0;
Why is this sort of thing needed? I thought that (size_t) -3 was
possible only after a low surrogate, which is possible when decoding
valid UTF-16 to Unicode, but no
I wrote:
> In mbrtoc32:
>
>Return value Consumed bytes
> --
>small n > 0n
>0 1
>(size_t)(-3) 0
>
> The patch below thus fixes the uses of mbrtoc32.
More of the same kind:
2023-07-02 Brun
This patch migrates the 'mbmemcasecoll' module from wchar_t to char32_t.
2023-07-02 Bruno Haible
mbmemcasecoll: Overcome wchar_t limitations.
* lib/mbmemcasecoll.c: Include instead of .
(apply_c32tolower): Renamed from apply_towlower. Use mbrtoc32 instead of
m
This patch migrates the 'mbswidth' module from wchar_t to char32_t.
2023-07-02 Bruno Haible
mbswidth: Overcome wchar_t limitations.
* lib/mbswidth.c: Include instead of .
(mbsnwidth): Use mbrtoc32 instead of mbrtowc. Use c32width instead of
wcwidth. Use c32isc
[CCing bug-libunistring, which is the better forum for topics like this.]
> > After a build of libunistring 1.1 I am running `make check` and am getting
> > 22 failures:
> >
> >
> >
> > Testsuite summary for
> >
> > =
Hi.
Bruno Haible wrote:
> Arnold: I have added '#if GAWK' conditionals, knowing that gawk's build system
> does not use gnulib-tool and you therefore pull from gnulib manually. This
> means the improvements will not land in gawk, since dfa in gawk will continue
> to use wchar_t.
Much thanks.
>
