On Thu, 9 Nov 2017, Martin Storsjö wrote:
On Thu, 9 Nov 2017, Jacek Caban wrote:
Hello,
On 11/9/17 11:10 AM, Martin Storsjö wrote:
On Thu, 9 Nov 2017, Kai Tietz via Mingw-w64-public wrote:
Hmm, C99 support is pretty important for the gnu world. Nevertheless
patch ok. Please go ahead.
Yup, I know. However, right now if you build with msvcrt.dll and use e.g.
wprintf(), you get the nonstandard behaviour unless you set
__USE_MINGW_ANSI_STDIO - and users probably rely on this behaviour, so I
don't want that to change surprisingly if moving from msvcrt.dll to
ucrtbase.dll.
Now that ucrtbase.dll-based builds start to work and you have a sense about
how well does it integrate with existing applications, could we please take
a
step back and talk about consistent strategy of compatibility. I understand
that we have backward compatibility to take care of, but we also have MSVC
compatibility that we need to take into account. I tend to divide
applications using mingw-w64 into two groups:
1. Applications supporting MSVC builds that also support mingw-w64 builds.
For them being as compatible with MSVC is a clear win. Otherwise, they need
additional special handling of mingw-w64 in places where we are not
compatible.
2. Applications using only mingw-w64 for Windows builds.
This group tend to depend on mingw-w64 quirks and it's the group that would
get hurt by backward incompatible mingw-w64 changes.
That said, your patch may make things easier for group 2, but hurts group
1.
The thing is that I think that new behavior is actually better - it's more
standard compliant. It's also more future-prove: at some point all
MSVC-compatible code will expect it. If we take this patch, 5 years from
now
we will be probably the only platform having legacy behavior by default.
Legacy behavior is a result of mistaken MS decision that are probably over
20
years old now. MS put a lot of work to move forward. I think it's about
time
we do the same and porting to new runtime library seems like a good moment
and opportunity to do that. New crt gives us tools for that, it would be
nice
to use them.
Note that supporting legacy behavior in this care is easy. One can achieve
that with -D__USE_MINGW_ANSI_STDIO=0. It doesn't even need code changes for
that, just setting CFLAGS. This should mitigate pain for projects depending
on legacy behavior.
This particular patch aside, I think general strategy for moving forward
should be: be as compatible with MSVC as possible, provide backward
compatible in places that are possible and make sense, but use porting to
new
runtime as a chance to break backward compatibility in places where it
makes
sense.
I imagine that others may have different opinions, so I think we should
discuss that here.
Ok - I can drop this patch then - I don't have a strict need for it
anywhere yet. I agree with your conclusions in general.
Just one detail:
Note that supporting legacy behavior in this care is easy. One can achieve
that with -D__USE_MINGW_ANSI_STDIO=0.
Not quite - if you're in an environment that defaults to ucrtbase, you
need to set
-DUCRTBASE_PRINTF_DEFAULT_WIDE=UCRTBASE_PRINTF_LEGACY_WIDE_SPECIFIERS or
something similar to get the legacy behaviour. Right now, you get the new,
standards compliant mode both with and without __USE_MINGW_ANSI_STDIO.
And on the topic of MSVC compatibility; in MSVC, what mode to use by
default is stored in a global variable, and you're supposed to link in a
special library that provides a different definition of this global
variable if you want a different default.
But as MSVC defaults to the new behaviour, I agree that it might be best
to do that in mingw-w64 for ucrtbase as well.
// Martin
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
