[Mingw-users] Deprecation of __USE_MINGW_ANSI_STDIO

Back to archive index
Keith Marshall keith****@users*****
Sun Jan 6 05:12:28 JST 2019

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

> 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

>     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.


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>

More information about the MinGW-Users mailing list
Back to archive index