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
