On Thu, 20 Aug 2026 13:34:59 -0700, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

scott@slp53.sl.home (Scott Lurndal) writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

...

Without dynamic linking, main() is the first code that runs when
the program is executed. It allocates its local variables in memory >>that's been zeroed by the OS.

Even without dynamic linking, the CRT (C Run-time) code will execute
before main() (often at a symbol called _start). I don't recall
any guarantee that the CRT code won't use the stack prior to invoking main.

Certainly. Just yesterday I wrote a toy test program using static
linking that invoked code before entry to main(), using gcc's `__attribute__((constructor))`.

Another real case: On Unix the shell normally expands filename
patterns (aka wildcards or globs) and passes the actual filenames to a
program. MS-DOS didn't (and now Windows doesn't) so DJGPP had a
feature to check for wildcard in an arg and expand before calling
main(). I believe, but haven't checked, that mingw[64?] also does.

I also had a bad Heisenbug for a similar reason, but not in C, on an
earlyish (1980s) multiuser system (thus clearing user processes to
zero) where the debugger ran in userspace, and left cruft above the
userspace stack. A particular program (in COBOL) sometimes crashed in production, but not when I tried to debug it, and I eventually found
it was the difference between the initially zero stack area and the
cruft from debugger startup that masked the bug.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 9/16/26 03:18, dave_thompson_2@comcast.net wrote:

Another real case: On Unix the shell normally expands filename
patterns (aka wildcards or globs) and passes the actual filenames to a program. MS-DOS didn't (and now Windows doesn't) so DJGPP had a
feature to check for wildcard in an arg and expand before calling
main(). I believe, but haven't checked, that mingw[64?] also does.

Same thing with the Microsoft C compiler v 5.x, you have
to add an .obj at link time to have the expansion of
joker arguments.

--
** **
* tTh des Bourtoulots *
* http://maison.tth.netlib.re/ *
** **

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 15 Sep 2026 21:18:36 -0400, dave_thompson_2 wrote:

Another real case: On Unix the shell normally expands filename
patterns (aka wildcards or globs) and passes the actual filenames to
a program. MS-DOS didn't (and now Windows doesn't) so DJGPP had a
feature to check for wildcard in an arg and expand before calling
main(). I believe, but haven't checked, that mingw[64?] also does.

The DOS/Windows command line architecture is fundamentally broken.

I also had a bad Heisenbug for a similar reason, but not in C, on an
earlyish (1980s) multiuser system (thus clearing user processes to
zero) where the debugger ran in userspace, and left cruft above the
userspace stack. A particular program (in COBOL) sometimes crashed
in production, but not when I tried to debug it, and I eventually
found it was the difference between the initially zero stack area
and the cruft from debugger startup that masked the bug.

Sounds like an implementation bug. Why does COBOL code need to
allocate any storage on the stack? Does the COBOL spec guarantee
anything about the initialization of storage? If so, those guarantees
must apply to any stack allocations that the implementation sees fit
to create. If not, then it?s a program bug.

--- PyGate Linux v1.5.19
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)