On 2/22/2020 2:54 PM, Martin Storsjö wrote:
Yes, one shouldn't use functions outside of that subset, or ideally
not link against msvcrt.dll at all. The proper solution to this is to
use UCRT instead - this is now possible since a few years.
I'm fairly sure that we rely on a number of functions outside of the
VC6 subset even before this patch (no I can't list the cases
off-hand). And restricting things to that subset isn't really an
option - if we wouldn't need to use such functions, we wouldn't.
Especially for simplifying compatibility between msvcrt.dll and UCRT,
we've been refactoring things and using a bit newer functions in a few
places, if I remember correctly.
Even if Microsoft _could_ ship an update to msvcrt.dll where they
wildly change the existing behaviour to any of the functions outside
of the VC6 subset that we might be using, chances are that they won't.
So in practice, we rely on whatever features of msvcrt.dll that are
available and have a stable behaviour from XP throughout versions up
to Win10. While we can't know for sure they won't change in the
future, it's a risk I think we're willing to take. The only proper
solution long term is to switch to the UCRT.
Even if using _vscprintf in MSVCRT.DLL is low risk the consequences are
severe because they potentially impact a lot of applications. Another
disadvantage of using _vscprintf is that it will prevent applications
from running on targets using older versions of MSVCRT.DLL. You stated
that we only care about Windows XP through Windows 10 but I can assure
you that there are people using MinGW that care about other targets.
For example I use MinGW in an embedded environment that links to the VC6
version of MSVCRT.DLL.
Considering the costs of linking to _vscprintf in MSVCRT.DLL what do we
gain? Future applications compiled under MinGW can start using the
return value of snprintf() when linking to MSVCRT.DLL? Is that a real
benefit? Future applications should be (1) using the MinGW internal
version of snprintf, (2) linking to the version in the UCRT, or (3)
avoiding snprintf altogether and calling _snprintf explicitly if they
want to use that.
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
