On 2025-01-28 Pali Rohár wrote: > I think that for excluding 8.3 names you mean to use FindExInfoBasic > level instead of FindExInfoStandard when doing FindFirstFileExW(). > > Level FindExInfoBasic is supported since Windows 7 and I think that > readdir() could be still useful also on Windows XP.
Thanks for noticing! I had only checked that FindFirstFileExW is an old thing but that didn't mean that FindExInfoBasic is very old too. So I will forget this idea, especially since 8.3 fallback could be useful. > > > Slightly off-topic, not related to readdir, but could be > > > interesting to check, what would happen if you call > > > setlocale(LC_ALL, ".UTF-8") before __getmainargs() call (which is > > > in mingw-w64 startup code crtexe.c)? Would this force UCRT to > > > pass argv[] in UTF-8 encoding into main() even without having > > > UTF-8 manifest? > > > > I didn't test but even if it worked, I suspect that ACP wouldn't > > become UTF-8 and thus argv[] and CRT wouldn't be in sync with Win32 > > *A() APIs. I *assume* that ACP is set fairly early, even before the > > first instruction is run from the executable. > > From your tests it looks like that setlocale(UTF-8) does not change > ACP but rather somehow instruct UCRT to use UTF-8 encoding for UCRT > narrow functions... and argv[] could be also treated as UCRT thing > and hence that was my idea if is also affected by setlocale or not. You idea is logical. The problem is that it would require applications to use some mingw-w64 extension. If they go that far, they could just use UTF-8 manifest. > > It's good to avoid the situation where CRT file system APIs use > > different encoding than the *A() functions. There is code around > > that uses both in parallel with the assumption that the encodings > > are the same. > > That is a good argument to avoid using setlocale(UTF-8) at all. Yes. Looking at Microsoft's docs, this setlocale functionality was added in Windows 10 version 1803. The UTF-8 manifest came a year later in 1903. Perhaps they had noticed that the locale-only method is not very usable. Now it has to be kept for backward compatibility. > I'm surprised, what else we find if we are going to continue in this > discussion? And how many security issues we have discovered which are > now just waiting for targeted exploits? :D :-) I suppose it needs quite a special situation where these issues cause more trouble than annoying breakage. After you have finished the startup code updates, I think it would be good if you could review my dirent update. It needs some tweaking and testing before I can send it. It's still clearly based on the old code but the modifications are big enough that there's no point to send it as a series of patches. *If* you find it good, only then it makes sense to propose it to the mingw-w64 maintainers. I'm aware that there is a possibility that it won't be accepted (ABI breakage etc.) but I'm fine with that. -- Lasse Collin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
