Re: [Mingw-w64-public] swscanf() crashes if __USE_MINGW_ANSI_STDIO is defined

On 2017/11/14 9:58, Liu Hao wrote: > On 2017/11/13 11:11, David Lee wrote: >> Built and tested a cross compiler (i686-w64-mingw32-gcc 6.4.0) on >> debian stretch with master mingw-w64. Same crash. >> > Yeah I just updated MSYS2's repos and observed the crash... can't imagine why > it didn't crash

Re: [Mingw-w64-public] swscanf() crashes if __USE_MINGW_ANSI_STDIO is defined

On 2017/11/13 11:11, David Lee wrote: Built and tested a cross compiler (i686-w64-mingw32-gcc 6.4.0) on debian stretch with master mingw-w64. Same crash. Yeah I just updated MSYS2's repos and observed the crash... can't imagine why it didn't crash a few days ago. The patch for mingw_vfscanf.c

[Mingw-w64-public] [PATCH] headers: Use _ftime32 instead of _ftime on ucrtbase

Signed-off-by: Martin Storsjö --- mingw-w64-headers/crt/sys/timeb.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mingw-w64-headers/crt/sys/timeb.h b/mingw-w64-headers/crt/sys/timeb.h index c92c8e0..ee947f0 100644 --- a/mingw-w64-headers/crt/sys/timeb.h +++ b/mingw-w64-headers/crt/sys/t

Re: [Mingw-w64-public] [PATCH] Revert "Avoid collisions for imported Interlocked symbols by VC generated code."

On Mon, 13 Nov 2017, Kai Tietz via Mingw-w64-public wrote: Hmm, I am not sure that this will actually fix just llvm, but break everything else. We provide the Interloced API as inline functions/builtins on gcc. Yes - for the functions that start with an underscore. The ones that don't staet

Re: [Mingw-w64-public] [PATCH] Revert "Avoid collisions for imported Interlocked symbols by VC generated code."

Hmm, I am not sure that this will actually fix just llvm, but break everything else. We provide the Interloced API as inline functions/builtins on gcc. So we don't want those symbols to be exported, as we want to use our own version instead. The reasoning is that such builtins might be optimizab

[Mingw-w64-public] [PATCH] Revert "Avoid collisions for imported Interlocked symbols by VC generated code."

This reverts commit bea244b471878eb6924463987eddb04cc581e306. Unfortunately this would also reintroduce the issue that commit fixed - but the commit doesn't elaborate on the details of those issues. We need to provide the version of these functions without a __imp_ prefix. Even though calling code

[Mingw-w64-public] [PATCH 1/3] crt: Extend i386/x64 aliases in msvcrt.def.in to arm/arm64 as well

These are pretty untested in practice, but as this is what the headers require based on e.g. _USE_32BIT_TIME_T, we need to provide matching aliases on arm and arm64 as well. Signed-off-by: Martin Storsjö --- mingw-w64-crt/def-include/func.def.in | 6 + mingw-w64-crt/lib-common/msvcrt.def.i

[Mingw-w64-public] [PATCH 2/3] headers: Make _{, w}find{first, next}32 the canonical name for the functions

For msvcrt.dll, the actual function is named without a -32 suffix but the suffixed version is provided as an alias in the import library. For msvcr*.dll and ucrtbase.dll, the actual function is named with the -32 suffix and the unsuffixed version is an alias. (The alias is missing in ucrtbase.dll.)

[Mingw-w64-public] [PATCH 3/3] crt: Map _find{first, next} to _find{first, next}32 on ucrtbase 32 bit x86

This is only to match what we do for msvcrt; the function name with a -32 suffix is the canonial that the headers should end up using. Signed-off-by: Martin Storsjö --- mingw-w64-crt/lib-common/ucrtbase.def.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mingw-w64-crt/lib-common/ucrtbas