[PATCH] wcwidth: adjust manpage input (Re: [PATCH] fix wcwidth to work with gcc 16 sign extension)
Thomas Wolff <[email protected]> Sat, 6 Jun 2026 10:40:11 +0200
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------kRlK0sa0rOyuJb6xdSKfnYLe Content-Type: multipart/alternative; boundary="------------9ZMTSSQOHY8c9bN193KcFpd4" --------------9ZMTSSQOHY8c9bN193KcFpd4 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable amending my code patch... sorry I didn't include this right away Am 04.06.2026 um 17:33 schrieb Jeff Johnston: > Patch applied.=C2=A0 Thanks. > > -- Jeff J. > > On Tue, Jun 2, 2026 at 8:43=E2=80=AFPM Thomas Wolff <[email protected]> wrot= e: > > 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.h= tml > > >>>> > >>> 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 con= verted > 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. > --------------9ZMTSSQOHY8c9bN193KcFpd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html> <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-= 8"> </head> <body> amending my code patch... sorry I didn't include this right away<br> <br> <div class=3D"moz-cite-prefix">Am 04.06.2026 um 17:33 schrieb Jeff Johnston:<br> </div> <blockquote type=3D"cite" cite=3D"mid:[email protected]= .com"> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUT= F-8"> <div dir=3D"ltr"> <div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif">Patch applied.=C2=A0 Th= anks.</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"gmail_quote gmail_quote_container"> <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]" moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext">towo@= towo.net</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);p= adding-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/cygwin/2026-April/259597.html" rel=3D"noreferrer" target=3D"_blank" moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext">https://cygwin.com/pipermail/c= ygwin/2026-April/259597.html</a><br> >>>>> as mentioned in<br> >>>>> <a href=3D"https://cygwin.com/pipermail/cygwin/2026-May/259734.html" rel=3D"noreferrer" target=3D"_blank" moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext">https://cygwin.com/pipermail/c= ygwin/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" moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext">https://gcc.gnu.org/bugzilla/s= how_bug.cgi?id=3D125451#c14</a><br> >>>>> attachment:<br> >>>> 0001-wchar.h-tweak-wcwidth-prototype-parameter-wchar_t-wi.patch<= br> >>>><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"noreferrer" target=3D"_blank" moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext">https://pubs.opengroup.org/onl= inepubs/9799919799/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> </body> </html> --------------9ZMTSSQOHY8c9bN193KcFpd4-- --------------kRlK0sa0rOyuJb6xdSKfnYLe Content-Type: text/plain; charset=UTF-8; name="0002-wcwidth-adjust-manpage-source-to-parameter-width-pat.patch" Content-Disposition: attachment; filename*0="0002-wcwidth-adjust-manpage-source-to-parameter-width-pat.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSBiMDgyZjlhMzEwOGI1Yzc2MjhhMzU5YWE3YTYzNjk2MDQ1N2UzMzY2IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBUaG9tYXMgV29sZmYgPHRvd29AdG93by5uZXQ+CkRh dGU6IFNhdCwgNiBKdW4gMjAyNiAwMDowMDowMCArMDAwMApTdWJqZWN0OiBbUEFUQ0hdIHdj d2lkdGg6IGFkanVzdCBtYW5wYWdlIHNvdXJjZSB0byBwYXJhbWV0ZXIgd2lkdGggcGF0Y2gK Ci0tLQogbmV3bGliL2xpYmMvc3RyaW5nL3djd2lkdGguYyB8IDM0ICsrKysrKysrKysrKysr KysrKysrKysrKysrKysrKystLS0KIDEgZmlsZSBjaGFuZ2VkLCAzMSBpbnNlcnRpb25zKCsp LCAzIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL25ld2xpYi9saWJjL3N0cmluZy93Y3dp ZHRoLmMgYi9uZXdsaWIvbGliYy9zdHJpbmcvd2N3aWR0aC5jCmluZGV4IGRmY2FhNmMyMS4u OTNjYzNlODI5IDEwMDY0NAotLS0gYS9uZXdsaWIvbGliYy9zdHJpbmcvd2N3aWR0aC5jCisr KyBiL25ld2xpYi9saWJjL3N0cmluZy93Y3dpZHRoLmMKQEAgLTcsMTUgKzcsMTcgQEAgSU5E RVgKIAogU1lOT1BTSVMKIAkjaW5jbHVkZSA8d2NoYXIuaD4KLQlpbnQgd2N3aWR0aChjb25z dCB3aW50X3QgPFt3Y10+KTsKKwlpbnQgd2N3aWR0aChjb25zdCB3Y2hhcl90IDxbd2NdPik7 CiAKIERFU0NSSVBUSU9OCiAJVGhlIDw8d2N3aWR0aD4+IGZ1bmN0aW9uIHNoYWxsIGRldGVy bWluZSB0aGUgbnVtYmVyIG9mIGNvbHVtbgogCXBvc2l0aW9ucyByZXF1aXJlZCBmb3IgdGhl IHdpZGUgY2hhcmFjdGVyIDxbd2NdPi4gVGhlIGFwcGxpY2F0aW9uCiAJc2hhbGwgZW5zdXJl IHRoYXQgdGhlIHZhbHVlIG9mIDxbd2NdPiBpcyBhIGNoYXJhY3RlciByZXByZXNlbnRhYmxl Ci0JYXMgYSB3aW50X3QgKGNvbWJpbmluZyBVbmljb2RlIHN1cnJvZ2F0ZSBwYWlycyBpbnRv IHNpbmdsZSAyMS1iaXQKLQlVbmljb2RlIGNvZGUgcG9pbnRzKSwgYW5kIGlzIGEgd2lkZS1j aGFyYWN0ZXIgY29kZSBjb3JyZXNwb25kaW5nIHRvIGEKKwlhcyBhIHdjaGFyX3QsIGFuZCBp cyBhIHdpZGUtY2hhcmFjdGVyIGNvZGUgY29ycmVzcG9uZGluZyB0byBhCiAJdmFsaWQgY2hh cmFjdGVyIGluIHRoZSBjdXJyZW50IGxvY2FsZS4KKwlOb3RlIHRoYXQgZm9yIGEgVW5pY29k ZSBjaGFyYWN0ZXIgb3V0c2lkZSB0aGUgMTYtYml0IHJhbmdlLCAKKwl0aGUgYXBwbGljYXRp b24gbXVzdCBzcGxpdCBpdCBpbnRvIFVuaWNvZGUgc3Vycm9nYXRlcyAKKwlhbmQgdXNlIHRo ZSA8PHdjc3dpZHRoPj4gZnVuY3Rpb24gaW5zdGVhZC4KIAogUkVUVVJOUwogCVRoZSA8PHdj d2lkdGg+PiBmdW5jdGlvbiBzaGFsbCBlaXRoZXIgcmV0dXJuIDAgKGlmIDxbd2NdPiBpcyBh IG51bGwKQEAgLTIzLDYgKzI1LDMwIEBAIFJFVFVSTlMKIAliZSBvY2N1cGllZCBieSB0aGUg d2lkZS1jaGFyYWN0ZXIgY29kZSA8W3djXT4sIG9yIHJldHVybiAtMSAoaWYgPFt3Y10+CiAJ ZG9lcyBub3QgY29ycmVzcG9uZCB0byBhIHByaW50YWJsZSB3aWRlLWNoYXJhY3RlciBjb2Rl KS4KIAorRVhBTVBMRQorCUFuIGFwcGxpY2F0aW9uIGZ1bmN0aW9uIHRvIGRldGVybWluZSB0 aGUgd2lkdGggb2YgYSAyMS1iaXQgCisJVW5pY29kZSBjaGFyYWN0ZXIgbWF5IGxvb2sgbGlr ZSB0aGlzOgorCisJCXR5cGVkZWYgdW5zaWduZWQgaW50IHVjaGFyX3Q7CisJCS8vIGRldGVy bWluZSBoaWdoIGFuZCBsb3cgc3Vycm9nYXRlcyBvZiBVbmljb2RlIGNoYXJhY3RlcgorCQl3 Y2hhcl90IGhpc3Vycih1Y2hhcl90IHhjKQorCQl7CisJCSAgcmV0dXJuIDB4RDgwMCB8ICgo KHhjIC0gMHgxMDAwMCkgPj4gMTApICYgMHgzRkYpOworCQl9CisJCXdjaGFyX3QgbG9zdXJy KHVjaGFyX3QgeGMpCisJCXsKKwkJICByZXR1cm4gMHhEQzAwIHwgKHhjICYgMHgzRkYpOwor CQl9CisKKwkJLy8gZGV0ZXJtaW5lIHdpZHRoIG9mIDIxLWJpdCBVbmljb2RlIGNoYXJhY3Rl cgorCQlpbnQgdWN3aWR0aCh1Y2hhcl90IHVjKQorCQl7CisJCSAgaWYgKHVjIDwgMHgxMDAw MCkKKwkJICAgIHJldHVybiB3Y3dpZHRoKHVjKTsKKwkJICBlbHNlCisJCSAgICByZXR1cm4g d2Nzd2lkdGgoKHdjaGFyX3RbXSl7aGlzdXJyKHVjKSwgbG9zdXJyKHVjKX0sIDIpOworCQl9 CisKIFBPUlRBQklMSVRZCiA8PHdjd2lkdGg+PiBoYXMgYmVlbiBpbnRyb2R1Y2VkIGluIHRo ZSBTaW5nbGUgVU5JWCBTcGVjaWZpY2F0aW9uIFZvbHVtZSAyLgogPDx3Y3dpZHRoPj4gaGFz IGJlZW4gbWFya2VkIGFzIGFuIGV4dGVuc2lvbiBpbiB0aGUgU2luZ2xlIFVOSVggU3BlY2lm aWNhdGlvbiBWb2x1bWUgMy4KQEAgLTE2NSw2ICsxOTEsOCBAQCBiaXNlYXJjaCh3aW50X3Qg dWNzLCBjb25zdCBzdHJ1Y3QgaW50ZXJ2YWwgKnRhYmxlLCBpbnQgbWF4KQogCiBpbnQKIF9f d2N3aWR0aCAoY29uc3Qgd2ludF90IHVjcykKKy8vIHVubGlrZSB3Y3dpZHRoLCB0aGUgcGFy YW1ldGVyIHR5cGUgb2YgX193Y3dpZHRoIG11c3QgYmUgMzIgYml0cyB3aWRlCisvLyBpbiBv cmRlciB0byBzdXBwb3J0IHdjc3dpZHRoCiB7CiAjaWZkZWYgX01CX0NBUEFCTEUKICAgLyog c29ydGVkIGxpc3Qgb2Ygbm9uLW92ZXJsYXBwaW5nIGludGVydmFscyBvZiBFYXN0IEFzaWFu IEFtYmlndW91cyBjaGFycyAqLwotLSAKMi41MS4wCgo= --------------kRlK0sa0rOyuJb6xdSKfnYLe--