DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 64VIPaea2811137 Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 64VIPaea2811137 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=H6B26EdZ X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 704694BA79A2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1780251935; bh=zWCtfMJv8h52piSXhlfhO1iLuruihfzdsAkLc+MyLcU=; h=To:Subject:In-Reply-To:References:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=H6B26EdZahoSnA6QMbUPzTJZgsS1QgGF6pdRfByexmEHto8JLg6vhEu80JawyAjsc PCy1k2jNjLGRQdOmjIEmF9YxK/B2M6Xd50tG2ObuN6WSwN3eh+zfqfvYv+bs/7Qxcs z0mxcEALF+LXQ5rSi2Fe6i1gEEge25nJLgsvxa+U= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2F2F34BA23F6 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2F2F34BA23F6 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1780251914; cv=none; b=aAvzXNN+uu7hTyvF2gExappXg7J64MdVnlRcSssXxHHnw5VLaqmR7JmYGxF/hO9aC1fo7Hyvj2dzdJI5I2k0NtiuQxuyzAFn/l0mcxf2yU/g7g7ovnY3vGqXd7BhSrqdp/RO0d/gRUCBSDiHFmffYL/XHI4CKyQijbOPVtPlN4g= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1780251914; c=relaxed/simple; bh=yrtNVMYymCRHVovslymnLG3Wyv8cKwE0x9bmQfI11kg=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=DCcVtORnA0qZPnmwujJlqll7pma1TJVVLSTg6blR1FtV0OgUO1qxDXeTDGapzNv/+RgItkL1je24MZ4kER4VGJGw4/MSIrFBdkCImf0AXliBAvcXoh31P/nVkfT/V0pycYZe52jfDDeR6RJWSHvuWdGDEPL08hWX528KQEmcMQI= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, secure) header.d=nexgo.de header.i=@nexgo.de header.a=rsa-sha256 header.s=vfde-mb-mr2-23sep header.b=HniKe92w DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2F2F34BA23F6 To: cygwin AT cygwin DOT com Subject: Re: wcwidth broken with gcc 16 In-Reply-To: <2a39e204-bd8b-4511-bd34-703899600e9e@towo.net> (Thomas Wolff via Cygwin's message of "Sun, 31 May 2026 18:53:14 +0200") References: <874ikpawdk DOT fsf AT Gerda DOT invalid> <8ff2ab8d-dfdc-459c-96f3-ed4a4f451440 AT towo DOT net> <0140C1F4-CA22-46DE-AE21-69C5427C59B5 AT unified-streaming DOT com>

<4f885156-7772-43d7-ab72-c88f0a7d1e52 AT towo DOT net> <112594ad-3c25-4dad-b1bc-071b4951ed98 AT towo DOT net> <97f0f3c6-9f2c-429c-aa8e-875b7806b275 AT towo DOT net> <8733z9jpfj DOT fsf AT Gerda DOT invalid>

<87pl2bab08 DOT fsf AT Gerda DOT invalid> <2a39e204-bd8b-4511-bd34-703899600e9e AT towo DOT net> Date: Sun, 31 May 2026 20:25:04 +0200 Message-ID: <87ldcza133.fsf@Gerda.invalid> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-purgate-server: smtpa07 X-purgate-type: clean X-purgate: clean X-purgate-size: 2202 X-purgate-ID: 155817::1780251911-1E4CF746-733F376D/0/0 X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: ASSI via Cygwin Reply-To: ASSI Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Thomas Wolff via Cygwin writes: > cygwin has changed it already by defining wchar_t as 16-bit. My fix > only reverts this. Nope. That's not a Cygwin thing and wchar_t can be anything, even less than 16bit, as far as the standards are concerned. Yes, that's messy, but it is what it is. >> The fix for your bug is easy enough > It's just not a fix because it narrows the parameter to 16 bits and > thus breaks current wcwidth functionality. It doesn't break anything that wasn't already broken before. There can be no correct Cygwin program that can use an argument to wcwidth that has more than 16 bits (and your own example doesn't use any of these anyway). The public interface always was wchar_t (nee unsigned short on Cygwin) and the extension to the win_t in the implementation function in newlib libc just wasn't working as you (still?) seem to think it does when you mismatch the types. The type extension of function arguments (via register sharing) on x86_64 is undefined, the resulting upper 16 bits in this case (wchar_t --> wint_t) can be anything: zero extension, sign extension or even random bits. This is just not something that can work reliably. I don't know what aarch64 does on that front. In your example, you use an int as argument, which is used as a function argument declared as short unsigned (via wchar_t, so it gets truncated to 16 bit, at least logically) and then used an int again inside the actual implementation of that function. This is wrong as the prototype and the implementation don't match, but the ABI only guarantees that the lower 16 bit of the original argument transfer in that case. Even if zero extension was used you'd lose any upper bits in the original argument anyway (which you say works for your example and I'd argue that there can't be any upper bits anyway on Cygwin, see aboive), which is exactly what will _definitely_ happen if the libc implementation stub is reverted to the correct signature. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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