On Monday 30 December 2024 15:32:16 Martin Storsjö wrote: > On Thu, 12 Dec 2024, Martin Storsjö wrote: > > > On Thu, 12 Dec 2024, LIU Hao wrote: > > > > > 在 2024-12-12 21:17, Martin Storsjö 写道: > > > > On Thu, 28 Nov 2024, Pali Rohár wrote: > > > > > msvcrt.dll preinstalled as part of the Windows system provides more > > > > > functions than the original Visual C++ 6.0, but still it is > > > > > compatible with > > > > > the original version. So setting __MSVCRT_VERSION__ to 0x600 > > > > > for msvcrt.dll > > > > > build is relatively sane option. > > > > > > > > > > I was considering to use 0x6FF value for this case, but this > > > > > would make it > > > > > more complicated for applications if they need to know if they are > > > > > being > > > > > compiled for msvcrt.dll library ABI. They would need to > > > > > check if the macro > > > > > __MSVCRT_VERSION__ is set to 0x600 (targetting the original > > > > > VC++ msvcrt.dll > > > > > library) or to value 0x6FFF (targettting the system msvcrt.dll > > > > > library). > > > > > This looks to be additional complication as it would be > > > > > needed to track all > > > > > possible values for __MSVCRT_VERSION__. So using just one value 0x600 > > > > > for > > > > > both cases should be enough because for system version > > > > > specific version is > > > > > always needed to check also _WIN32_WINNT value. > > > > > > > > I think this change looks reasonable to me, but I'd like Liu > > > > Hao, who suggested the 0x6FF version, to follow up here. > > > > > > I'm fine with this change, too. > > > > Thanks, I pushed this one now then. > > It turns out that this change did cause some breakage in user projects - see > https://github.com/msys2/MINGW-packages/pull/22907. > > Also see > https://codesearch.debian.net/search?q=if.*__MSVCRT_VERSION__.*0x0*%5B76%5D&literal=0&page=2 > - it seems that there are a number of other projects that also have > conditionals relating to this, which also may run into trouble. > > (E.g. with old mingw.org headers, functions like _aligned_malloc used to be > guarded within "#if __MSVCRT_VERSION__ >= 0x0700", so some projects either > check __MSVCRT_VERSION__ to know whether it is available, or even try to set > __MSVCRT_VERSION__ themselves in order to opt in to using such functions, > that were available in msvcrt.dll since XP.) > > Not saying that this requires revisiting our decision, but it may cause some > amount of confusion and breakage in existing user code out there. > > // Martin
That is not good. But I do not know what can be done better. If the application is using #if __MSVCRT_VERSION__ >= ... and one of the preprocessor branch result in broken compiled application then it is obviously bug in application. But I do not know what to do with it. Either we need to say that the whole __MSVCRT_VERSION__ macro is now broken because it is wrongly used by applications and we should rather deprecate it (by providing some fixed value to let application compile) and create a new macro e.g. __MSVCRT_VERSION_REAL__ which would contain the real version. Or we need to say that it is application bug and do not care about it. Or maybe completely remove __MSVCRT_VERSION__ macro and always provides all function declarations in header files. But I think that any of those options just cause new problems. This does not have a sane solution at all. Whatever solution is chosen, I would propose to put big warning into release notes what is happening and how application code could be adjusted. _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
