Re: [PATCH] wchar.h: tweak wcwidth prototype parameter wchar_t -> wint_t

Thomas Wolff <[email protected]> Mon, 1 Jun 2026 18:02:31 +0200
Newsgroups gmane.comp.lib.newlib
Message-ID <[email protected]>
Am 31.05.2026 um 13:57 schrieb Takashi Yano:
> Hi Thomas,
>
> On Sun, 31 May 2026 10:06:12 +0200
> Thomas Wolff wrote:
>> Hi Brian,
>>
>> Am 31.05.2026 um 05:50 schrieb Brian Inglis via Cygwin:
>>> On 2026-05-28 22:58, Thomas Wolff wrote:
>>>> to make it compliant with newlib and the manual page;
>>>> fixes cases of wrong width calculation:
>>>> https://cygwin.com/pipermail/cygwin/2026-April/259597.html
>>>> as mentioned in
>>>> https://cygwin.com/pipermail/cygwin/2026-May/259734.html
>>>> as described in
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D125451#c14
>>>> attachment:
>>> 0001-wchar.h-tweak-wcwidth-prototype-parameter-wchar_t-wi.patch
>>>
>>> The existing wcwidth declaration in newlib/libc/include/wchar.h agrees
>>> with
>>> POSIX 8 SUS V5.
>>>
>>> It is the man doc, definition, and implementation in
>>> newlib/libc/string/wcwidth.c which need changed to match the
>>> specification and return codes in:
>>>
>>>  =C2=A0=C2=A0=C2=A0=C2=A0https://pubs.opengroup.org/onlinepubs/9799919=
799/functions/wcwidth.html
>> Your argument overlooks one significant deviation: in POSIX, wchar_t ha=
s
>> 32 bits, in cygwin only 16.
>> So to make wcwidth work for *all* Unicode character code points, the 32
>> bit version must be used.
>> I tested positively that this fixes the broken test case with gcc 16 I
>> had reported to the cygwin list.
> However, newlib is not used only by Cygwin, so I think newlib itself sho=
uld
> follow POSIX. Shouldn't we have our own wcwidth() implementation for Cyg=
win?
>
> On second thought, since a 16=E2=80=91bit wchar_t needs to be converted =
to a 32=E2=80=91bit
> Unicode code point especially for surrogate pair, we cannot use wcwidth =
in
> the same way as Linux does. I wonder what the correct approach would be.
I don't there is a "correct" approach as POSIX probably did not consider=
=20
this problem.
But I just responded to a cute idea on the cygwin mailing list, which=20
was unfeasible but I modified it with a proposal to return width 1 for a=
=20
high surrogate, remember it, and then return 1 or 0 for the low=20
surrogate, respectively.