Liu Hao 2017-09-27 15:32:
Jon would you please cherry-pick it to v5.x? Thanks.
Jon, ping please.
--
Regards, niXman
___
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
https://sf.net/p/mingw-w64/
On 09/29/2017 08:48 PM, Martin Storsjö wrote:
> Previously, the ifdefs were misplaced, leading to this function not
> being defined at all if building with __USE_MINGW_ANSI_STDIO=1.
>
> If targeting ucrtbase.dll, we always need to rely on the
> __stdio_common_vsprintf implementation, since _vscpri
On Fri, 29 Sep 2017, Martin Storsjö wrote:
By avoiding turning fprintf(stderr,) into fwrite(stderr,) we can localize
the compat wrapping for that to fprintf. Then we shouldn't ever need to
worry about functions needing init_compat to be called before they're
invoked by the constructor.
This all
Previously, the ifdefs were misplaced, leading to this function not
being defined at all if building with __USE_MINGW_ANSI_STDIO=1.
If targeting ucrtbase.dll, we always need to rely on the
__stdio_common_vsprintf implementation, since _vscprintf doesn't
exist in ucrtbase.dll, regardless of the sta
On Fri, 29 Sep 2017, Jacek Caban wrote:
Please review.
Signed-off-by: Jacek Caban
---
mingw-w64-headers/crt/stdio.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
This actually isn't correct for the cases when building with
__MSVCRT_VERSION__ = 0x1400.
I'll post another version th
Please review.
Signed-off-by: Jacek Caban
---
mingw-w64-headers/crt/stdio.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mingw-w64-headers/crt/stdio.h b/mingw-w64-headers/crt/stdio.h
index 34aae9ad..0d9cf1c7 100644
--- a/mingw-w64-headers/crt/stdio.h
+++ b/mingw-w64-h
By avoiding turning fprintf(stderr,) into fwrite(stderr,) we can localize
the compat wrapping for that to fprintf. Then we shouldn't ever need to
worry about functions needing init_compat to be called before they're
invoked by the constructor.
This allows simplifying the ucrtbase_compat.c code qui
Now the output from the unified msvcrt.def.in should be almost identical
to what it was before, except for some new *_dbg and __p_* functions.
The functions that were included for 32 and 64 bit x86 in the unification
were originally believed to be harmless, but some of them turned out to
be functi
