DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 651K5TRb3824932
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 609004BA2E09
To: cygwin@cygwin.com
Subject: Re: wcwidth broken with gcc 16
In-Reply-To: <5c46f199-128c-4409-a354-9d3e1deb29bb@towo.net> (Thomas Wolff via
 Cygwin's message of "Mon, 1 Jun 2026 10:13:01 +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>
 <87pl2bab08.fsf@Gerda.invalid>
 <2a39e204-bd8b-4511-bd34-703899600e9e@towo.net>
 <87ldcza133.fsf@Gerda.invalid>
 <21ca1d38-7b82-49af-b954-b83141237843@towo.net>
 <5c46f199-128c-4409-a354-9d3e1deb29bb@towo.net>
Date: Mon, 01 Jun 2026 22:04:21 +0200
Message-ID: <87y0gyyqm2.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:
>> 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.

>> 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.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

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