Re: wcwidth broken with gcc 16

Am 01.06.2026 um 22:04 schrieb ASSI via Cygwin:
> Thomas Wolff via Cygwin writes:
>>> 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.
> It makes a difference on Cygwin because wchar_t and wint_t are not the
> same width (and wchar_t is not supposed to be signed anyway even if they
> were).
>
>>> Especially when it would make things binary incompatible?
>> I don't see any incompatibilites that might arise on cygwin.
> Exactly the same one that had you open a bug for gcc: a compiler that
> uses wchar_t for the argument does not need to care about any upper bits
> left in the register that will go into the function and the function
> call (taking a win_t) does.  Whether there actually are any binaries
> that have this problem is left as an exercise for the reader, but the
> mere possibility for one to exist makes this a no-go.
So you refer to previously-compiled programs. Acknowledged, I hadn't 
considered that.
(Doesn't affect gcc before 16 and clang but anyway.)
So I'll withdraw my patch and provide another one, tomorrow.
(If gcc weren't so weird to bit-extend a 16-bit argument at all, in the 
first place, the bug would have been apparent earlier.)

>>> 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.
> Again, there is no existing code that can produce such a result (given
> how wchar_t is currently defined and was from the very beginning), so
> there is nothing to fix.  And you can't change it without invalidating
> existing binaries.
>
>> 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.
> Nobody ever suggested that.  IIRC the internal function __wcwidth that
> is called through the stub implementation has always been taking a
> wint_t.  I don't know if there's a precedent for an additional API
> function (most certainly not POSIX) that exists on systems that have the
> same characteristics as Windows (and Cygwin) of wchar_t not quite large
> enough to fit all codepoints in order to enable that functionality via
> either a wint_t or some additional unsigned wchar-like type.
>
>
> 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