On Sun, 5 Jan 2025, Pali Rohár wrote:
Another idea how to handle this problem, so the application would have
access to declaration of >= 0x0700 functions.
Remove all __MSVCRT_VERSION__ checks in mingw-w64 header files which
hide msvcr* functions, and then revert back the default
__MSVCRT_VERSION__ value to 0x0700.
That's certainly also an option, but I'm not sure if this is the best one
either...
This would essentially mean that we should revert
797b4a6b51916d3d1c934d80a7b3d1725099f325,
f1df976e39063a5da7795af79b65b6dbbc60c432 (and maybe
e445c779dd34ac692332dd7b0bccd376e67662ba?), and by doing that, we
reintroduce whatever problems there were that they were meant to fix, if
any.
One of these commits, f1df976e39063a5da7795af79b65b6dbbc60c432, indicates
that it fixes https://github.com/mingw-w64/mingw-w64/issues/60. But when
reading that issue, it is very unclear to me what the actual root issue
was - was it only confusion about why functions are declared which are not
available for linking? Or was there a technical issue somewhere that was
linked to these functions, but which also was fixed differently elsewhere
(within msys2)? I don't see how this change itself would fix anything,
other than the fact that we have inconsistent declarations.
One reason for why we might want to have tight/correct ifdefs around
functions, is if there are user projects that have build systems, that try
to detect what functions are available (at the configure stage). By
compiling with strict enough flags, it's enough to do a compile-only test
(no need to test linking) to see if such functions are available. (And for
functions which are available in msvcrt.dll on a later OS version, such a
case does need to check declarations strictly, because if it relies on
linker tests, it would see that linking does succeed (as our .def file
does have the symbols, meant for later versions).
So in general, I think it is useful to have correct ifdefs around header
declarations - that makes it clearer to everybody where each function is
expected to be usable. (We don't need to go out of our way to add it
around everything though, but in the cases where somebody has taken care
to add it, they might have a reason for it.)
So with this in mind, I still think that going for 0x6FF probably would be
a reasonable compromise; it avoids issues for some user code which has got
checks for 0x0601 (but not all such issues). We haven't heard back about
any more cases of breakage due to this (although the code search does show
which cases we may run into).
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
