On Saturday 09 November 2024 21:30:53 Lasse Collin wrote: > On 2024-11-09 LIU Hao wrote: > > Really, I don't think this should be fixed in the CRT. It should be > > fixed by sanitizing the result in `GetCommandLineA()`. Reverting the > > commit makes sense if Microsoft will fix it sooner or latter. > > My point comment approving a revert was in context that then a better > fix will be done. For example, including a GUI dialog to display the > error in GUI apps. > > > I have a crazy idea now. Does it make sense to overwrite `_acmdln` > > (for MSVCRT) or `*__p__acmdln()` (for UCRT) with a sanitized string, > > so existent argument parsing may be reused?
It looks like that both _acmdln and _wcmdln are initialized in CRT DLL entry point. And these variables are used by all other calls, GetCommandLineA() or GetCommandLineW() are not used later. So from this quick look, it should be enough to change _acmdln in mingw-w64 startup code as early as possible and then __getmainargs() should work fine (it also uses _acmdln and not GetCommandLineA(), at least in msvcrt.dll). > If wildcard expansion is enabled, things can still go wrong if a > wildcard matches a filename that cannot be converted losslessly to the > active code page. Maybe stupid question, but what happens when you try to list folder which contains files which names in active code page are all same? Imagine that you have an application which does not use argv[] at all, it list files in the current directory and from every file prints for example first byte. What would happen in this case? Is not here same problem as with wildcard expansion? > If wildcard expansion is disabled, then it should be enough to verify > that GetCommandLineW() can be losslessly converted to the active code > page. Then the existing narrow parser should be safe. > > -- > Lasse Collin _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
