On Monday 30 December 2024 18:50:57 Pali Rohár wrote:
> 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.
I was thinking more about this problem... It looks like that most
"problematic" SW either check or set __MSVCRT_VERSION__ macro against
value 0x0601.
What about setting __MSVCRT_VERSION__ to value 0x0601 in configure phase
and then in header files just do relaxed check that upper word is 0x06?
#if (__MSVCRT_VERSION__ >> 8) == 0x06
... compiling for system msvcrt.dll ...
#endif
So whatever 0x06?? value the application code choose, mingw-w64 header
files would interpret it as using system msvcrt.dll.
If I'm looking correctly at this, it should also fix the problem with
OSGeo/gdal project.
And maybe instead of 0x0601 set it in configure phase to 0x06FF what
Liu Hao suggested?
PS: Nice tool for regex searching across public git repositories is
sourcegraph.com:
https://sourcegraph.com/search?q=context:global+if.*__MSVCRT_VERSION__.*0x&patternType=regexp&sm=0
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
