MSVCRT.DLL's _pgmptr variable is uninitialized by MinGW start-up code
keith keith keith keith The following (trivial) program illustrates the issue:
If I compile this, with default settings for _CRT_glob, link with current mingwrt, and run it (under MSYS) on a Win7, or WinXP VM, I see:
$ mingw32-gcc t-pgmptr.c -o pgmptr.exe $ ./pgmptr.exe _pgmptr = '(null)'OTOH, if I compile it with -D_CRT_GLOB=1, or with -D_CRT_GLOB=0, either of which causes the mingwrt start-up code to call Microsoft's __getmainargs(), I see (as expected):
$ mingw32-gcc -D_CRT_GLOB=1 t-pgmptr.c -o pgmptr.exe $ ./pgmptr.exe _pgmptr = 'e:\sandbox\pgmptr.exe'
keith keith keith keith keith The attached patch resolves the anomaly. I will include it in the next mingwrt release.
keith This is fixed, in mingwrt-5.4.2.
Fork
According to Microsoft's GetModuleFileNameA() function documentation:
It appears that this global variable initialization occurs, only if the run-time start-up code calls Microsoft's __getmainargs() function, but that exhibits defective globbing of wild-card patterns, and MinGW has not used it, as a default start-up hook, since the release of mingwrt-3.21, in December 2014. Consequently, references to _pgmptr, in code linked against mingwrt-3.21 (and later), are likely to dereference a NULL pointer.