On 05/01/19 12:13, Eli Zaretskii wrote: > I've installed the latest MinGW runtime 5.2 today, and hit this snag: > > In file included from d:/gnu/git/emacs/branch/nt/inc > /mingw_time.h:13:0, > from d:/gnu/git/emacs/branch/nt/inc/ms-w32.h:27, > from ../src/conf_post.h:35, > from ../src/config.h:2019, > from acl_entries.c:20: > 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". > 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. Indeed, I wonder just how many of those "many packages" take the trouble to define it properly, in terms of the other internal, and thus also "implementation-private" symbolic constant to which it *should* refer -- viz, __MINGW_ANSI_STDIO__; I'd guess *that* count is near zero. > and there's no good way of retrofitting them all to adapt to > this change. Well, they should have never adopted this malpractice, in the first instance; it may be painful, but they should be encouraged to mend their ways. > 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? 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. > . Using -Wno-cpp to shut up this warning will also shut up all the > warnings emitted by #warning, so is a too blunt instrument. I agree; better to eliminate the improper usage, and fix the problem. > . 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. > 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. > If not, then I respectfully request > that this warning be removed, as IMO it does more harm than help. > Unless I'm missing something important, the direct use of > __USE_MINGW_ANSI_STDIO is really a benign issue, and the deprecation > warning is only justified if __USE_MINGW_ANSI_STDIO is planned to be > removed in the foreseeable future. And I cannot imagine why we'd want > to remove __USE_MINGW_ANSI_STDIO at this stage. Is its removal really > planned? Removal, no; breaking future changes, OTOH, are a distinct possibility. > 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 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. -- Regards, Keith. Public key available from keys.gnupg.net Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F -------------- next part -------------- A non-text attachment was scrubbed... Name: 14-mingw-ansi-stdio-misuse.patch Type: text/x-patch Size: 1359 bytes Desc: not available URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20190105/7283e98d/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20190105/7283e98d/attachment.sig>
Fork