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
