Re: GB18030 locale

2023-07-31 Thread Corinna Vinschen via Cygwin
Hi Bruno, On Jul 31 12:07, Corinna Vinschen via Cygwin wrote: > On Jul 29 11:53, Bruno Haible via Cygwin wrote: > > Corinna Vinschen wrote: > > > However, on debugging this, I see it's totally broken. Trying to fix > > > this in the existing functions is futile. We need dedicated > > > support

Re: GB18030 locale

2023-07-31 Thread Corinna Vinschen via Cygwin
On Jul 29 11:53, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > However, on debugging this, I see it's totally broken. Trying to fix > > this in the existing functions is futile. We need dedicated > > support functions for GB18030, kind of like the FreeBSD functions, > > just with

Re: GB18030 locale

2023-07-29 Thread Bruno Haible via Cygwin
Corinna Vinschen wrote: > However, on debugging this, I see it's totally broken. Trying to fix > this in the existing functions is futile. We need dedicated > support functions for GB18030, kind of like the FreeBSD functions, > just with extra support for surrogate pairs, as with our UTF8 stuff.

Re: GB18030 locale

2023-07-29 Thread Corinna Vinschen via Cygwin
On Jul 28 21:54, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > test-fnmatch-5.sh is SKIPped because we don't support zh_CN.GB18030. > > Hmm? When I read winsup/cygwin/release/3.5.0 and the commit > 5da71b6059956a8f20a6be02e82867aa28aa3880, it seems the zh_CN.GB18030 > locale

Re: GB18030 locale

2023-07-28 Thread Bruno Haible via Cygwin
Corinna Vinschen wrote: > test-fnmatch-5.sh is SKIPped because we don't support zh_CN.GB18030. Hmm? When I read winsup/cygwin/release/3.5.0 and the commit 5da71b6059956a8f20a6be02e82867aa28aa3880, it seems the zh_CN.GB18030 locale (which on native Windows is called "Chinese_China.54936") should