Re: wctomb() accepts out-of-range character in C-locale

[Corinna Vinschen <vinschen@redhat.com>]

Hi Bruno,

On Mar 25 12:26, Bruno Haible wrote:
> Hi Corinna,
> 
> > Jun T wrote:
> > > ---------------------------------------
> > > #include <stdio.h>
> > > #include <stdlib.h>
> > > #include <locale.h>
> > > 
> > > int main() {
> > >     char buf[MB_CUR_MAX];
> > >     setlocale(LC_ALL, "C");
> > >     printf("%d\n", wctomb(buf, 0x80));
> > >     return 0;
> > > }
> > > ---------------------------------------
> > > 
> > > On Linux it outputs '-1'.
> 
> "On Linux" is ambiguous:
>   - In glibc, it outputs -1 because of this glibc bug:
>     https://sourceware.org/bugzilla/show_bug.cgi?id=19932
>     https://sourceware.org/bugzilla/show_bug.cgi?id=29511
>   - In musl libc, it outputs -1 because the "C" locale (like all locales)
>     uses UTF-8 encoding and the lone byte "\x80" is not an entire character
>     in UTF-8.
> 
> > > But a wide character >= 0x80 can't be converted into a valid
> > > character in C-loccale (7bit), I think.
> 
> Err. "C" locale, a.k.a. "POSIX" locale, is not 7-bit but 8-bit.
> Quoting https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/V1_chap06.html#tag_06_02 :
>   "The POSIX locale shall contain 256 single-byte characters ..."

Yeah, now that you mention it... I should have thought of this myself :}

> > During testing I found that gnulib was replacing various functions built
> > into Cygwin for several reasons, and one of them was that the conversion
> > of wide char to multibyte in the "C" locale was not transparently
> > converting chars from 0x80 up to 0xff.
> 
> What you did is to make Cygwin POSIX compliant in this aspect, which is
> good.
> 
> > I'm actually puzzled right now that this doesn't work in GLibc either.
> 
> It's the aforementioned glibc bug.
> 
> > Do you have an idea what gnulib configure test might have been the
> > trigger for the above revert?
> 
> It's the "checking whether the C locale is free of encoding errors..." test
> (macro gl_MBRTOWC_C_LOCALE in m4/mbrtowc.m4).
> 
> Bruno

Great, so we're in the clear here.

Thanks a lot for your (as usual 👍) informative input!


Corinna