Re: wcwidth broken with gcc 16

Am 31.05.2026 um 18:53 schrieb Thomas Wolff via Cygwin:
>
> 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)
>>   {
Well, OK, I see what you mean. Changing the parameter width of the 
implementation would probably fix the cases from U+8000 to U+FFFF but 
the assignment below would not make any difference.
For characters > 0xFFFF, the prototype width extension would actually be 
needed independently from gcc versions, and I still claim it's the right 
thing to do, in compensation for the cygwin wchar_t limitation.

>>     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