Re: wcwidth broken with gcc 16

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>

-- 
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