Re: wcwidth broken with gcc 16

Am 31.05.2026 um 16:50 schrieb ASSI via Cygwin:
> Thomas Wolff via Cygwin writes:
>> The implementation was extended to wint_t some years ago just to
>> enable the functionality indicated above, and it used to work until
>> gcc 15.
> That was by accident and dependent on undefined behaviour in the
> compiler for x86_64 ABI, as explained to you already.
>
>> For some change in gcc 16, it is now necessary to adapt the prototype
>> too, or gcc will apply the wrong extension and yield broken results.
> You don't own the prototype of a standardised public API function and
> don't get to change it for that very reason.
cygwin has changed it already by defining wchar_t as 16-bit. My fix only 
reverts this.

> The fix for your bug is easy enough
It's just not a fix because it narrows the parameter to 16 bits and thus 
breaks current wcwidth functionality.

> and I don't get why you insist making it even more wrong instead.
Because it's not wrong but the right thing to do as I had explained before.

>
> --8<---------------cut here---------------start------------->8---
> diff --git a/newlib/libc/string/wcwidth.c b/newlib/libc/string/wcwidth.c
> index 8348eefe8..65604c061 100644
> --- a/newlib/libc/string/wcwidth.c
> +++ b/newlib/libc/string/wcwidth.c
> @@ -230,7 +230,7 @@ __wcwidth (const wint_t ucs)
>   }
>   
>   int
> -wcwidth (const wint_t wc)
> +wcwidth (const wchar_t wc)
>   {
>     wint_t wi = wc;
>   
> --8<---------------cut here---------------end--------------->8---
>
> Again, the assignment of wc to wi should do the proper zero extension
> you seek and keeps the public signature intact (and that was what the
> code did before your change).  The stub then calls the implementation
> __wcwidth (which does take a wint_t argument), there just is no way of
> feeding it codepoints above 16 bit (and there never was such a
> possibility for correct code in Cygwin).
>
> Now I get that you think that
>
> sizeof(wchar_t) == sizeof(wint_t)
>
> should hold like on all GNU systems, but that isn't the case since
> Cygwin is on Windows and so WCHAR_MAX == 0xffffu (I think you know the
> backstory to that).  So you cannot have code points beyond 16 bits as
> input to wcwidth anyway and everything else is treated correctly (and as
> before and after the change).  Whether there needs to be a separate API
> for dealing with such codepoints (essentially in UTF-32) is a separate
> discussion.
>
>
> 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