DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 64VEpM4C2708972
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B38CA4BA2E22
To: cygwin@cygwin.com
Subject: Re: wcwidth broken with gcc 16
In-Reply-To: <b8c1571a-1956-4316-a6a9-32176b6c7c80@towo.net> (Thomas Wolff via
 Cygwin's message of "Sun, 31 May 2026 10:10:12 +0200")
References: <a9676834-0368-4a8a-88b0-da5e9483b536@towo.net>
 <874ikpawdk.fsf@Gerda.invalid>
 <8ff2ab8d-dfdc-459c-96f3-ed4a4f451440@towo.net>
 <0140C1F4-CA22-46DE-AE21-69C5427C59B5@unified-streaming.com>
 <e94174b7-ea9b-45ca-bfd3-7979ce988920@towo.net>
 <e362b49c-521c-4cd5-8963-c17d5770619b@SystematicSW.ab.ca>
 <fbbeb91a-4c5a-dbe6-1bb3-206cf14a73bc@wisemo.com>
 <4f885156-7772-43d7-ab72-c88f0a7d1e52@towo.net>
 <112594ad-3c25-4dad-b1bc-071b4951ed98@towo.net>
 <97f0f3c6-9f2c-429c-aa8e-875b7806b275@towo.net>
 <8733z9jpfj.fsf@Gerda.invalid>
 <b70d8366-8970-4cdc-a693-6d826fe76277@towo.net>
 <b8c1571a-1956-4316-a6a9-32176b6c7c80@towo.net>
Date: Sun, 31 May 2026 16:50:47 +0200
Message-ID: <87pl2bab08.fsf@Gerda.invalid>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Precedence: list
From: ASSI via Cygwin <cygwin@cygwin.com>
Reply-To: ASSI <Stromeko@nexgo.de>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>

Thomas Wolff via Cygwin writes:
> 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.

That was by accident and dependent on undefined behaviour in the
compiler for x86_64 ABI, as explained to you already.

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

You don't own the prototype of a standardised public API function and
don't get to change it for that very reason.

The fix for your bug is easy enough and I don't get why you insist
making it even more wrong instead.

--8<---------------cut here---------------start------------->8---
diff --git a/newlib/libc/string/wcwidth.c b/newlib/libc/string/wcwidth.c
index 8348eefe8..65604c061 100644
--- a/newlib/libc/string/wcwidth.c
+++ b/newlib/libc/string/wcwidth.c
@@ -230,7 +230,7 @@ __wcwidth (const wint_t ucs)
 }
 
 int
-wcwidth (const wint_t wc)
+wcwidth (const wchar_t wc)
 {
   wint_t wi = wc;
 
--8<---------------cut here---------------end--------------->8---

Again, the assignment of wc to wi should do the proper zero extension
you seek and keeps the public signature intact (and that was what the
code did before your change).  The stub then calls the implementation
__wcwidth (which does take a wint_t argument), there just is no way of
feeding it codepoints above 16 bit (and there never was such a
possibility for correct code in Cygwin).

Now I get that you think that

sizeof(wchar_t) == sizeof(wint_t)

should hold like on all GNU systems, but that isn't the case since
Cygwin is on Windows and so WCHAR_MAX == 0xffffu (I think you know the
backstory to that).  So you cannot have code points beyond 16 bits as
input to wcwidth anyway and everything else is treated correctly (and as
before and after the change).  Whether there needs to be a separate API
for dealing with such codepoints (essentially in UTF-32) is a separate
discussion.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

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