DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 60QF0xMt1561326
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 60QF0xMt1561326
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=BINikZ0d
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org DD1F34BA9004
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1769439658;
	bh=EkeeYeiDPsggZr26SYgJGr/T005sAeeMW1MhRxC0ePU=;
	h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=BINikZ0d7G9E2wPw0NarMeciYcPI8lBTOVXYOuenCYY31AaSdzAg6RPX53pANvbM5
	1VjS4ebMXI1iDmHm4eHOYGxI91WiqC7Eu9RtsYtLdgAxkHd5+V3QReuRg2nJxrUzSM
	CSUKvMSwQU1iLpEY0Uo12rWaHHvTdq4OEHbwATbQ=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org E242A4BC8952
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org E242A4BC8952
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1769439639; cv=none;
	b=ahT2tPGqTBifP3C86WfI0YeKYVFtU6ohkWbdI6AT4Qcb9O0t7KstOHCRAEnoduwPwbVA3BjtGX7++gnlU/E0bV35mN8Urm63BnOIfRtxcRvxxYEUO5lmvUhyZ5KADiYezLDPyT3Vm/wN+9mu4rBDF2sIjqobWrWb2poGSHMgp5Q=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1769439639; c=relaxed/simple;
	bh=4ypAVBbH102RCpKP5iIMpF7GaT/6AzuXza5RCJOMjOw=;
	h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;
	b=vwwrJqYjicP05vXIvm1A2j3WTLr6ZiF+HEbEJ8rq4tGd8srk5S3k4XD5r2G2IRt1wIELF0OmBBLOjpqp0XTH9yz9jqECuCsAmuYl4iZbHy59lqcEW1uoWQDN/uJZAIYSdYhRWvLbb+TdD+v/2wxKdL0fpWtn94KfHGW7yMrTFnk=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org E242A4BC8952
X-Barracuda-Envelope-From:	moss AT cs DOT umass DOT edu
X-Barracuda-RBL-Trusted-Forwarder:	128.119.240.136
DKIM-Filter:	OpenDKIM Filter v2.11.0 mailsrv.cs.umass.edu 21F6B5BDA1
X-Barracuda-RBL-Trusted-Forwarder:	172.26.69.67
Message-ID:	<168f8b39-968b-1c82-1145-83a72ccc4ec8@cs.umass.edu>
Date:	Mon, 26 Jan 2026 10:00:27 -0500
MIME-Version:	1.0
User-Agent:	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
	Thunderbird/102.15.1
Subject:	Re: Utterly perplexing change in behaviour
X-ASG-Orig-Subj:	Re: Utterly perplexing change in behaviour
To:	Fergus Daly <fergusd84 AT outlook DOT com>,
	"'cygwin AT cygwin DOT com'" <cygwin AT cygwin DOT com>
References:	<PA1P189MB3532D3F8D25CFF338C8F2983A493A AT PA1P189MB3532 DOT EURP189 DOT PROD DOT OUTLOOK DOT COM>
In-Reply-To:	<PA1P189MB3532D3F8D25CFF338C8F2983A493A@PA1P189MB3532.EURP189.PROD.OUTLOOK.COM>
X-Barracuda-Connect:	mailsrv.cs.umass.edu[128.119.240.136]
X-Barracuda-Start-Time:	1769439633
X-Barracuda-Encrypted:	TLS_AES_256_GCM_SHA384
X-Barracuda-URL:	https://barramail.cs.umass.edu:443/cgi-mod/mark.cgi
X-Barracuda-BRTS-Status:	1
X-Virus-Scanned:	by bsmtpd at cs.umass.edu
X-Barracuda-Scan-Msg-Size:	3618
X-ASG-Debug-ID:	1769439633-24039d4da51ac520001-w5GHUG
X-Barracuda-Spam-Score:	0.00
X-Barracuda-Spam-Status:	No, SCORE=0.00 using global scores of TAG_LEVEL=3.5
	QUARANTINE_LEVEL=10.0 KILL_LEVEL=9.7 test=
X-Barracuda-Spam-Report:	Code version 3.2, rules version 3.2.3.125474
	Rule breakdown below
	pts rule name description
	---- ---------------------- --------------------------------------------------
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Eliot Moss via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Eliot Moss <moss AT cs DOT umass DOT edu>
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

On 1/26/2026 9:48 AM, Fergus Daly via Cygwin wrote:
> This pertains to an external executable built within Cygwin and therefore not part of any Cygwin package so I am not expecting a "solution"
> but any illumination whatsoever, or similar experience, would be much appreciated.
> 
> I use a standalone static statistical executable built within Cygwin from a collection of .c files using gcc.
> The resulting executable comprises many built-in functions and procedures ("routines").
> Typically it would be used within the Cygwin environment where it is supported by large libraries of data files, Help files and call-able routines.
> But it is sophisticated enough to be useful within a directory containing just two files, itself myprog.exe and cygwin1.dll.
> So you could start it in a Command Prompt window with the command .\myprog <Enter> with no need of Cygwin's larger architecture.
> 
> It has a built-in function Cygwin() which returns the scalar 1 within Cygwin.
> (The identical collection of .c files may be used with gcc in Linux to build the equivalent executable for use in Linux.
> Then the function Cygwin() returns 0. There are cases where this distinction requires to be drawn.)
> This has been going for literally decades with trivial fixes and enhancements and surviving all advances over the years in cygwin1.dll
> or the Linux kernel and upgrades to gcc.
> 
> As mentioned here a while ago the only glitch in its construction is that I have to use /lib/libreadline.a from v.8.1-2 [prev] not v.8.3-1 [curr]
> though I have not been able to pinpoint quite why. I just do the temporary workaround and then back again.
> 
> Oh dear: sorry for this tedious preamble. Now to the point of this communication:
> 
> Recently some common behaviours stalled, and it emerged that the function Cygwin() returned 0 not 1.
> This is astonishing because
> (a) I made no changes to the executable or to its environment.
> Well, I would say that, wouldn't I but .. ..
> (b) I could not recover the required functionality by reverting to an earlier version of cygwin1.dll;
> (c) the wrong output occurred on an old machine where W11 was not recently updated; and
> (d) the wrong output occurred on an even older machine running W10.
> All previously error-free. Unaltered executable !! Finally, even more incredibly bizarre:
> (e) I recompiled the executable twice in succession. With the same trigger, one version returned the value 1 as needed. The other again returned 0.
> 
> I know. I know. Being of non-Cygwin origin; and with no access to the source collection; and with no oversight of my key-presses (especially at  (e))
> this amounts to no more than a fringe anecdote. But it would be hugely encouraging to know of any similar experience of inexplicably changed behaviour
> (especially if recent) or any kind of a hint of cause or cure.
> 
> Thank you for wading through all this .. ..

Just a thought, prompted by decades of debugging experience ...

Could this maybe have to do with uninitialized data, particularly some local variable?
What's in a stack location would be whatever was left behind by some previous function.
Also, while globals probably default to some standard value (e.g., 0) even if not
initialized, maybe that's not always true.  For example, I'm not sure what value would
be in thread-local storage that is not explicitly initialized.

I'm wondering if valgrind might be of assistance here in determining whether reference
to uninitialized data may be happening.  (This would be valgrind's memcheck tool.)

Regards - Eliot Moss

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

- Raw text -