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
