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

[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=125451#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:
> >
> >     https://pubs.opengroup.org/onlinepubs/9799919799/functions/wcwidth.html
> Your argument overlooks one significant deviation: in POSIX, wchar_t has 
> 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 should
follow POSIX. Shouldn't we have our own wcwidth() implementation for Cygwin?

On second thought, since a 16‑bit wchar_t needs to be converted to a 32‑bit
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.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>