On Friday 10 January 2025 12:32:41 Martin Storsjö wrote:
> On Mon, 6 Jan 2025, Pali Rohár wrote:
>
> > All 32-bit Windows NT systems contains system OS library msvcrt40.dll which
> > should be compatible with the original Visual C++ 4.0/4.1 msvcrt40.dll
> > library.
> >
> > The Windows NT implementation of msvcrt40.dll is very simple, it just
> > redirects function calls via symbol forwarding to msvcrt.dll library.
> >
> > Since Windows XP, the msvcrt.dll changed ABI of __getmainargs() and
> > __wgetmainargs() functions, and so it is required also for msvcrt40.dll
> > builds to include ABI fix code which is already used for msvcrt.dll builds.
> > Otherwise applications compiled with new mingw-w64 checks introduced since
> > commit 3e043834e993 ("crt: Check for return value from __(w)getmainargs()
> > calls") would crash on Windows XP+ systems if they would use the system
> > msvcrt40.dll library.
>
> I don't understand why they would crash?
I have not explained it correctly. As msvcrt40.dll __getmainargs()
redirects to msvcrt.dll __getmainargs(), it means that msvcrt40 builds
have exactly same issues as msvcrt builds. For msvcrt builds we provide
that wrapper for fixing fails.
> If they are compiled with misc/msvcrt40__getmainargs.c, they end up calling
> msvcrt40.dll's __getmainargs(), ignoring any return value from it, as it is
> expected to have a void return type.
>
> If that code runs on a newer msvcrt40.dll (which redirects to msvcrt.dll,
> with the new ABI), I don't see how things would crash? On success, it should
> work just fine. _If_ there's a failure in it, we would miss it though - as
> misc/msvcrt40__getmainargs.c expects that the function terminates the
> process on error, while it would just return an error code and expect the
> caller to handle it.
The issue is on the failure code path. misc/msvcrt40__getmainargs.c is
ignoring return value from msvcrt40.dll's __getmainargs() and is
returning 0 even when __getmainargs() failed. WinXP+ msvcrt40.dll does
not terminate process on error and expects caller to handle failure.
Crash can happen because crt startup code thinks that argv was properly
filled when it returns 0, but on failure it is not (and 0 is still
returned). Application main() code then dereference argv and NULL
pointer dereference happens.
> So I don't understand this patch from the point of view of how it is
> explained. The change itself looks acceptable from the point of view of "fix
> catching error cases on msvcrt40.dll" though.
>
> // Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
