Re: wcwidth broken with gcc 16
Thomas Wolff via Cygwin <[email protected]> Mon, 1 Jun 2026 10:13:01 +0200
| Newsgroups | gmane.os.cygwin |
|---|---|
| Message-ID | <[email protected]> |
Am 01.06.2026 um 07:04 schrieb ASSI via Cygwin:
> Thomas Wolff via Cygwin writes:
>> You explain what I had already conceded before, that I had overlooked
>> the prototype and the intended functionality did not work:
>> printf("%d\n", wcwidth(0x13000)); // should be 1
>> printf("%d\n", wcwidth(0x1F500)); // should be 2
>>
>> So why not establish that functionality with an easy tweak that does
>> not interfere with anything?
> Which part of "you must not change a standard public API" is unclear to you?
Who defines that? Reference? After all, it would be a compatible
extension, not the most unusal thing to do.
> Especially when it would make things binary incompatible?
I don't see any incompatibilites that might arise on cygwin.
> WCHAR_MAX is 0xffffu on Cygwin, so the above is illegal input to wcwidth and it never worked.
Well, my proposal was just to make it work. But you may well argue it
doesn't need to.
If you patch wcwidth.c as you suggest, make sure however *not* to
bit-reduce __wcwidth because that would break wcswidth which must
continue to work for non-BMP characters passed as surrogate pairs.
Kind regards
Thomas
> Regards,
> Achim.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple