Control: merge -1 897196 Hi,
On Fri, 10 Jan 2020 22:43:27 +0100, Bernhard Übelacker <[email protected]> wrote: > In the regular case the resulting exe seems to link > to msvcrt.dll!_vsnprintf: > > $ i686-w64-mingw32-objdump --private-headers test.c.exe > DLL Name: msvcrt.dll > vma: Hint/Ord Member-Name Bound-To > 63e8 766 _vsnprintf > > Under wine we then get to that location: > #0 0x7eb514d6 in MSVCRT_vsnprintf (str=0x65fe64 "", len=3, > format=0x40400b "abcdef", valist=0x65fe5c "+\026@") > at /home/benutzer/wine/wine-git/wine-git/dlls/msvcrt/wcs.c:686 > > The resulting executables are showing the same output > in wine and windows. Yes; this is a bug in MSVCRT. > In the posix case it seems the snprintf implementation is > not taken from any dll, instead it is contained inside > the executable, therefore supplied by the compiler? > > Microsoft states [1], that they switched in VS2015 snprintf > to be C99 compliant, wouldn't therefore snprintf in msvcrt.dll > not compliant? > > Is this issue in the end that mingw should link to > newer c-library by default? I’m not sure what the exact fix should be, apart from building with -posix or #define __USE_MINGW_ANSI_STDIO 1. This is filed upstream as https://sourceforge.net/p/mingw-w64/bugs/709/ (and CVE-2018-1000101), and apparently MSVCRT’s vsnprintf does the right thing now, but I haven’t had the time to figure out how to use that correctly yet. Regards, Stephen
pgpNwCtBc1dUt.pgp
Description: OpenPGP digital signature
