Re: [PATCH] wcwidth: adjust manpage input (Re: [PATCH] fix wcwidth to work with gcc 16 sign extension)
Jeff Johnston <[email protected]> Mon, 8 Jun 2026 17:26:45 -0400
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <CAOox84vMDYWBL6=2rkjQOZgqONj0GaUuQjuCDXJM_XySmQdOFw@mail.gmail.com> |
--000000000000a2ffdd0653c4abf0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Patch applied. -- Jeff J. On Sat, Jun 6, 2026 at 4:40=E2=80=AFAM Thomas Wolff <[email protected]> wrote: > amending my code patch... sorry I didn't include this right away > > Am 04.06.2026 um 17:33 schrieb Jeff Johnston: > > Patch applied. Thanks. > > -- Jeff J. > > On Tue, Jun 2, 2026 at 8:43=E2=80=AFPM Thomas Wolff <[email protected]> wrote= : > >> As discussed in the cygwin thread, I withdraw my previous patch and >> provide the attached one to fix wcwidth for gcc 16. >> Thomas >> >> Am 01.06.2026 um 18:02 schrieb Thomas Wolff: >> > >> > 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: >> >>>> >> >>>> >> 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=E2=80=91bit wchar_t needs to be convert= ed 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 this problem. >> > But I just responded to a cute idea on the cygwin mailing list, which >> > was unfeasible but I modified it with a proposal to return width 1 for >> > a high surrogate, remember it, and then return 1 or 0 for the low >> > surrogate, respectively. >> > > --000000000000a2ffdd0653c4abf0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:verdana,= sans-serif">Patch applied.</div><div class=3D"gmail_default" style=3D"font-= family:verdana,sans-serif"><br></div><div class=3D"gmail_default" style=3D"= font-family:verdana,sans-serif">-- Jeff J.</div></div><br><div class=3D"gma= il_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sa= t, Jun 6, 2026 at 4:40=E2=80=AFAM Thomas Wolff <<a href=3D"mailto:towo@t= owo.net">[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_q= uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2= 04);padding-left:1ex"><u></u> =20 =20 =20 <div> amending my code patch... sorry I didn't include this right away<br= > <br> <div>Am 04.06.2026 um 17:33 schrieb Jeff Johnston:<br> </div> <blockquote type=3D"cite"> =20 <div dir=3D"ltr"> <div class=3D"gmail_default" style=3D"font-family:verdana,sans-seri= f">Patch applied.=C2=A0 Thanks.</div> <div class=3D"gmail_default" style=3D"font-family:verdana,sans-seri= f"><br> </div> <div class=3D"gmail_default" style=3D"font-family:verdana,sans-seri= f">-- Jeff J.</div> </div> <br> <div class=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jun 2, 2026 at 8:43= =E2=80=AFPM Thomas Wolff <<a href=3D"mailto:[email protected]" target=3D"_blan= k">[email protected]</a>> wrote:<br> </div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex= ;border-left:1px solid rgb(204,204,204);padding-left:1ex">As discussed in the cygwin thread, I withdraw my previous patch and <br> provide the attached one to fix wcwidth for gcc 16.<br> Thomas<br> <br> Am 01.06.2026 um 18:02 schrieb Thomas Wolff:<br> ><br> > Am 31.05.2026 um 13:57 schrieb Takashi Yano:<br> >> Hi Thomas,<br> >><br> >> On Sun, 31 May 2026 10:06:12 +0200<br> >> Thomas Wolff wrote:<br> >>> Hi Brian,<br> >>><br> >>> Am 31.05.2026 um 05:50 schrieb Brian Inglis via Cygwin:<br> >>>> On 2026-05-28 22:58, Thomas Wolff wrote:<br> >>>>> to make it compliant with newlib and the manual page;<br> >>>>> fixes cases of wrong width calculation:<br> >>>>> <a href=3D"https://cygwin.com/pipermail/cygw= in/2026-April/259597.html" rel=3D"noreferrer" target=3D"_blank">https://cyg= win.com/pipermail/cygwin/2026-April/259597.html</a><br> >>>>> as mentioned in<br> >>>>> <a href=3D"https://cygwin.com/pipermail/cygw= in/2026-May/259734.html" rel=3D"noreferrer" target=3D"_blank">https://cygwi= n.com/pipermail/cygwin/2026-May/259734.html</a><br> >>>>> as described in<br> >>>>> <a href=3D"https://gcc.gnu.org/bugzilla/show= _bug.cgi?id=3D125451#c14" rel=3D"noreferrer" target=3D"_blank">https://gcc.= gnu.org/bugzilla/show_bug.cgi?id=3D125451#c14</a><br> >>>>> attachment:<br> >>>> 0001-wchar.h-tweak-wcwidth-prototype-parameter-wchar_t-wi.patch<b= r> >>>><br> >>>> The existing wcwidth declaration in newlib/libc/include/wchar.h agrees<br> >>>> with<br> >>>> POSIX 8 SUS V5.<br> >>>><br> >>>> It is the man doc, definition, and implementation in<br> >>>> newlib/libc/string/wcwidth.c which need changed to match the<br> >>>> specification and return codes in:<br> >>>><br> >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<a href=3D"https:/= /pubs.opengroup.org/onlinepubs/9799919799/functions/wcwidth.html" rel=3D"no= referrer" target=3D"_blank">https://pubs.opengroup.org/onlinepubs/979991979= 9/functions/wcwidth.html</a> <br> >>>><br> >>> Your argument overlooks one significant deviation: in POSIX, wchar_t <br> >>> has<br> >>> 32 bits, in cygwin only 16.<br> >>> So to make wcwidth work for *all* Unicode character code points, the 32<br> >>> bit version must be used.<br> >>> I tested positively that this fixes the broken test case with gcc 16 I<br> >>> had reported to the cygwin list.<br> >> However, newlib is not used only by Cygwin, so I think newlib itself <br> >> should<br> >> follow POSIX. Shouldn't we have our own wcwidth() implementation for <br> >> Cygwin?<br> >><br> >> On second thought, since a 16=E2=80=91bit wchar_t needs = to be converted to a <br> >> 32=E2=80=91bit<br> >> Unicode code point especially for surrogate pair, we cannot use <br> >> wcwidth in<br> >> the same way as Linux does. I wonder what the correct approach would be.<br> > I don't there is a "correct" approach as POSIX= probably did not <br> > consider this problem.<br> > But I just responded to a cute idea on the cygwin mailing list, which <br> > was unfeasible but I modified it with a proposal to return width 1 for <br> > a high surrogate, remember it, and then return 1 or 0 for the low <br> > surrogate, respectively.<br> </blockquote> </div> </blockquote> <br> </div> </blockquote></div> --000000000000a2ffdd0653c4abf0--