Am 25.05.2026 um 18:53 schrieb Thomas Wolff via Cygwin:
Am 05.05.2026 um 08:37 schrieb Thomas Wolff via Cygwin:
Am 04.05.2026 um 23:52 schrieb Jakob Bohm via Cygwin:
On 03/05/2026 18:14, Brian Inglis via Cygwin wrote:
On 2026-05-03 06:00, Thomas Wolff via Cygwin wrote:
Am 03.05.2026 um 12:58 schrieb Dimitry Andric:
On 3 May 2026, at 12:47, Thomas Wolff via Cygwin
<[email protected]> wrote:
Am 03.05.2026 um 07:35 schrieb ASSI via Cygwin:
Thomas Wolff via Cygwin writes:
Observed with gcc 16:
For a number of character ranges, mainly (but not only) from CJK
ranges, wcwidth incorrectly reports width 1 instead of 2, 0,
or -1.
Test file attached.
Can you report this upstream, please?
I couldn't yet test it with gcc 16 on Linux as there is no
Debian package.
Did you test it?
It looks like BSD-based libc gives 1 for U+D7C6, U+D7CB and
U+D7CB, while glibc gives 0.
Thanks. Despite some differences, none of them gives the broken
results of gcc-16 on cygwin, so I wonder whether it makes sense to
report upstream at this time.
It appears that libiberty does not contain any mb/wc
macros/functions, , and only contains safe-ctype IS...
macros/functions with fixed ASCII characters.
Does gcc, like most GNU products, include some release of gnulib?
Could gnulib or gcc config detect some lack of support and "fix"
newlib-cygwin support of Unicode properties declared in
wchar.h/wctype.h, or used in i18n, libunistring, and Unicode string
functions, especially if doing any kind of cross-bootstrap?
https://www.gnu.org/software/gnulib/MODULES.html
I also note that w32api-headers/runtime are gcc runtime
dependencies and hope they are used only in COFF/PE-related
generation?
Under Cygwin, does wcwidth() use Cygwin-provided table, derived
either from upstream Unicode data or from Windows OS APIs that use
OS bundled Unicode data?
Cygwin/newlib provides a wcwidth function that uses a table generated
from unicode.org data, but apparently gcc 16 does not (fully?) use
that function.
Now reported upstream: 125451 – wcwidth broken with gcc 16 on cygwin
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125451>
As discussed in the upstream issue, it may because by the include file
which specifies:
int wcwidth (const wchar_t);
although the parameter type should be wint_t (as it is in newlib) to
support full Unicode.
gcc 16 sign-extends the parameter to a signed 16-bit value, while
earlier gcc zero-extends it to an unsigned.
Why it extends a short value for an assumed short parameter at all, and
why the signedness of this extension changed in gcc 16, remains obscure
for now.
(Maybe further discussion in the upstream issue will shed light on this.)
But in any case I guess it would help to fix the include file and make
it consistent with both newlib and the wcwidth manual page.
Thomas
--
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
