On 2023-07-12 12:45, Bruno Haible wrote:
I would feel more confident if this would be discussed on libc-alpha sooner
than later
Fair enough, I'll try to remember to do that after the next release.
Paul Eggert wrote:
> > Well, since I reported
> > https://sourceware.org/bugzilla/show_bug.cgi?id=30611 ,
> > I expect to see a change in glibc behaviour in this area. But binaries
> > compiled with a current glibc should continue to work fine with future
> > glibc versions. This means, we cannot
On 2023-07-11 11:39, Bruno Haible wrote:
Paul Eggert wrote:
Even if
mbsinit returns nonzero, things are still OK if further scanning behaves
as if the mbstate_t were all zero. Although this implementation behavior
would be silly, POSIX doesn't prohibit it
we don't need to bother about this situ
Paul Eggert wrote:
> > DEFINITION: We call an mbrtoc32 function_regular_ if
> >- It never returns (size_t)-3.
> >- When it returns < (size_t)-2, the mbstate_t is in the initial state.
>
> "the initial state" -> "an initial state". But even with that change
> isn't the second part of this
On 2023-07-10 15:45, Bruno Haible wrote:
DEFINITION: We call an mbrtoc32 function_regular_ if
- It never returns (size_t)-3.
- When it returns < (size_t)-2, the mbstate_t is in the initial state.
"the initial state" -> "an initial state". But even with that change
isn't the second part
In the thread "From wchar_t to char32_t" we discussed the mbrtoc32 function,
in particular.
mbrtoc32, compared to mbrtowc, has two new features:
(a) it overcomes wchar_t limitations, especially the fact that on Windows,
wchar_t is only 16 bits wide.
(b) it allows a multibyte sequence to
