Re: wcwidth broken with gcc 16

Am 30.05.2026 um 19:40 schrieb ASSI via Cygwin:
> Thomas Wolff via Cygwin writes:
>> The patch is already on the newlib mailing list.
> The input parameter is supposed to be wchar_t, not wint_t (per POSIX and
> also the previous implementation), so I#d leave that alone.
As also commented to Brian on the newlib list, this point of view does 
not consider that cygwin wchar_t is not POSIX wchar_t.
There's simply 16 bits missing, so a function wcwidth(wchar_t) would not 
be able to evaluate Unicode character code points beyond U+FFFF.
The bit-extension to wint_t is needed to compensate for the cygwin 
deviation in the wchar_t type.

>> Yeah, I forgot to type-extend also the include file back in 2018 :-(
>> but that made no difference so far, only now in gcc 16, as explained
>> by Drea in that issue:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125451#c16
> Just pun the type in the stub implementation, which would automatically
> happen (I think) since there's already an assignment of the input
> parameter from the POSIX wcwidth (wchar_t) to a local variable that has
> type wint_t.  And since that's not a function call but an assignment,
> the promotion rules should be correct for your application without any
> cast.
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.
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.
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