On Mon, 24 Feb 2020, Jacek Caban wrote:
On 24.02.2020 12:46, Jacek Caban wrote:
On 24.02.2020 12:28, Martin Storsjö wrote:
On Mon, 24 Feb 2020, Jacek Caban wrote:
Still, the problematic commit tries to solve some problems that are
already solved when using mingw-w64 *printf implementation. S
On 24.02.2020 12:46, Jacek Caban wrote:
On 24.02.2020 12:28, Martin Storsjö wrote:
On Mon, 24 Feb 2020, Jacek Caban wrote:
Still, the problematic commit tries to solve some problems that are
already solved when using mingw-w64 *printf implementation. Since
non-underscored does not exist in ms
On 24.02.2020 12:28, Martin Storsjö wrote:
On Mon, 24 Feb 2020, Jacek Caban wrote:
Still, the problematic commit tries to solve some problems that are
already solved when using mingw-w64 *printf implementation. Since
non-underscored does not exist in msvcrt.dll, it's our extension
anyway. So
On Mon, 24 Feb 2020, Jacek Caban wrote:
Still, the problematic commit tries to solve some problems that are already
solved when using mingw-w64 *printf implementation. Since non-underscored
does not exist in msvcrt.dll, it's our extension anyway. So how about making
it always use __mingw_vsnpr
Hi,
I think that the best way forward is UCRT. When using UCRT, there is
already no issue. We should probably revisit making that a default
configuration.
I don't agree with us trying to limit use to VC6 subset. Microsoft does
not intentionally break applications and I'm pretty sure that r
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
applicati
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 function
On Sat, 22 Feb 2020, Dan Raymond wrote:
The latter change raises a new issue because _vscprintf is not present
in the VC6 C-runtime library. The VC6 APIs are the only ones in
msvcrt.dll that we can rely on according to these blogs:
https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=12
Dne 22. 2. 2020 v 19:22 Dan Raymond napsal(a):
> I don't think there is any doubt that something needs to be done to fix this.
>
+1
Although I hope that any solution would still allow apps to explicly choose
the MSVCRTL.DLL if the app knows what it does. It may be written with that
runtime in
Pali Rohár recently raised an issue regarding snprintf() and he pointed
out a valid concern. The MinGW toolchain has been silently redirecting
snprintf() to the MSFT-specific non-conforming _snprintf(). This
creates a substantial security risk for any application compiled using
MinGW. When a
10 matches
Mail list logo
