> From: Keith Marshall <keith****@users*****> > Date: Sat, 5 Jan 2019 20:12:28 +0000 > > > d:\usr\include\_mingw.h:383:3: warning: #warning "Direct > > definition of __USE_MINGW_ANSI_STDIO is deprecated." [-Wcpp] > > # warning "Direct definition of __USE_MINGW_ANSI_STDIO is > > deprecated." > > ^~~~~~~ > > d:\usr\include\_mingw.h:384:10: note: #pragma message: > > See <_mingw.h> for preferred feature activation methods. > > # pragma message "See <_mingw.h> for preferred feature > > activation methods." > > ^~~~~~~ > > > > This deprecation warning is going to be a terrible nuisance, > > Nuisance? I think that's a bit of an overstatement. Sure, you get a > bit of extra warning noise, (perhaps even significant extra noise), but > the behaviour remains unchanged ... "deprecated" is not the same as > "discontinued". It's a nuisance because it produces a lot of noise, and real warnings can be easily overlooked in the noise. Moreover, some packages use "-Werror", at least when you build development snapshots, and that actually stops the build. > > > for the following reasons: > > > > . Many packages nowadays use -D__USE_MINGW_ANSI_STDIO or equivalent > > #define in their headers, > > Every one of those packages is broken; as the original architect of the > entire MinGW ANSI Stdio subsystem, I have always stated my disapproval > of such abuse of this "implementation-private" symbolic constant. That is probably so, but it's IMO too late to fix this, certainly by such quite radical measures. Especially since mingw.org's MinGW, sadly, is no longer regarded as the main MS-Windows target by free software developers. > > Moreover, the Gnulib's stdio.m4 macros emit a > > > > #define __USE_MINGW_ANSI_STDIO > > > > line into the package's config.h, when the package is being > > configured for MinGW, so any package that uses Gnulib will be > > hit by this. > > One might have hoped that the Gnulib folks would know better, but ah > well! Is there *really* no better feature test they could have chosen? I don't know. I guess they've done it for pragmatic reasons, and because they really don't know (and don't want to know) too much about MinGW. Someone told them this worked, so they picked it up. Who knows? > FWIW, GCC itself is another guilty abuser ... and needlessly so! GCC > had already defined one or other of _GNU_SOURCE or _XOPEN_SOURCE, and > either one of these is an implicit __USE_MINGW_ANSI_STDIO enabler. I > used the attached (conservative) patch, to silence the warnings, and > simultaneously, verify that the abusive definition was never needed anyway. I can always maintain private patches like that, but I thought it would be possible to avoid that. > > . The place where the warning is emitted, _mingw.h, makes a bad > > situation even worse, because that header is needed to identify > > mingw.org's MinGW and distinguish between it and MinGW64 (which > > doesn't have __MINGW_FEATURES__ and uses __USE_MINGW_ANSI_STDIO). > > Even if a package does want to switch to using __MINGW_FEATURES__, > > I don't see how to do that in a way that will not adversely affect > > a MinGW64 build of the same package. > > I am under no obligation to constrain my own future development plans, > to support the renegade mingw-w64 fork from our own code-base. I don't care much about MinGW64 either. But upstream package maintainers will never accept patches that break compilation with MinGW64, which is nowadays considered the main MinGW target (I have seen package maintainers surprised mingw.org's MinGW is still being actively developed and used). To be accepted, any such patches need to cater to MinGW64, and it's practically impossible when the warning comes out of _mingw.h. > > Did I miss some reasonable way of shutting up this warning and > > switching to __MINGW_FEATURES__? > > I don't think so, but then, I don't want this warning to be silenced -- > I want other project maintainers to take note of it, and to stop > misusing this implementation-private feature test; I'd like you to help > nag them into compliance. I don't think this is practical, sorry. Certainly not if we cannot come up with a remedy that doesn't break MinGW64 builds. > > At the very least, if there must be such a warning, please move it to > > stdio.h, so that a package could include _mingw.h early on without > > triggering the warning, and then #undef __USE_MINGW_ANSI_STDIO as > > needed. > > That really would be a breaking change ... now! I deliberately chose to > emit a deprecation warning, without any breaking change for the time > being; I meant emitting the warning from stdio.h, like is done for __USE_MINGW_FSEEK. > I could just as easily have exercised my right to change the > internal use of this implementation-private feature, without notice, > and so break all of those "many packages" that currently abuse it. That'd be shooting MinGW users in the foot, I think. Thanks.
Fork