I've been thinking some more about this and maybe we are going about it
wrong. How did we get here in the first place? I don't know the entire
history of MinGW but I suspect this came about from the very early days
when people were trying to port Unix applications to Windows. Those
applications were making heavy use of snprintf which was not available
on Windows. The options at the time were to handle this at the
application level (manually convert snprintf calls to _snprintf in the
source files) or at the compiler level (redirect snprintf to _snprintf
in the system headers). For reasons of expediency the latter was
chosen. Today things are different. Now we have a c99-conformant
version of snprintf that is bundled with MinGW and another one that is
bundled with the UCRT. It is no longer necessary to redirect snprintf
to the non-conformant _snprintf in MSVCRT.DLL (and to accept the
resulting security risks). But we are doing just that and worse that is
the default configuration. Moving forward we want to (1) fix the
security hole in existing applications when they are recompiled with the
latest MinGW toolchain and (2) prevent future applications from creating
the security hole in the first place.
The patch submitted by Pali attempts to accomplish this transparently by
wrapping _snprintf in a way that *almost* makes it behave the same as
snprintf. But there are problems with that approach. It creates a
dependency on another API in MSVCRT.DLL which is not always present and
may be removed at any time and it doesn't fix the problem with
incompatible format specifiers.
Maybe we shouldn't try to do this transparently. Instead we could stop
redirecting snprintf to _snprintf altogether. Yes, this will cause
build failures for existing applications when they upgrade to the latest
MinGW toolchain. But that is a good thing because it will force them to
look at their security holes and address them in whatever way they
choose. That could be creating their own snprintf to _snprintf wrapper
to go back to the way they were doing it. Or it could be defining the
macro that causes the MinGW version of snprintf to be used. Or it could
be linking to the UCRT instead of MSVCRT.DLL. This will also be better
for future applications because they will be forced to make that choice
from the very beginning.
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
