> From: Keith Marshall <keith****@users*****> > Date: Sat, 5 Jan 2019 21:09:51 +0000 > > > There's a similar problem with __USE_MINGW_FSEEK. The warning for > > that one is emitted by stdio.h, so it's a little bit easier to fix. > > But the alternative, to set _WIN32_WINDOWS to something smaller than > > 0x0500, is also somewhat problematic, since it requires conditionals > > that do it only for mingw.org's MinGW (because MinGW64 supports only > > Vista and later). > > And we committed to continuing legacy support, (IIRC, you were a strong > advocate for that commitment). But why is it a problem, anyway? > AFAICT, __USE_MINGW_FSEEK serves *no useful purpose whatsoever*, on > *any* platform which is not Win9x, so why do mingw-w64 still have it? No, __USE_MINGW_FSEEK is indeed not relevant to MinGW64. The problem is specific to MinGW. But the solution, to define _WIN32_WINDOWS, might create a problem for MinGW64. > And why is it a problem if *both* _WIN32_WINNT and _WIN32_WINDOWS are > defined? The former is explicitly related to support levels on WinNT > derived platforms, while the latter is exclusive to Win9x; IAC, there is > no fundamental reason why you cannot declare an intent to support Win9x > to (say) _WIN32_WINDOWS_ME, and simultaneously require > _WIN32_WINNT_WIN2K or later on WinNT; AFAIK, MinGW.org headers no longer > restrict API visibility on the basis of any _WIN32_WINDOWS definition, > (unless it's an API which is exclusive to, or differently implemented > on, Win9x). Maybe it's just my lack of knowledge, then. > > It would be easier if the warning about __USE_MINGW_FSEEK is also > > removed, as the entire GCC/GDB/Binutils chain uses it, for example. > > I don't recall seeing any related warnings, when I built GCC-8.2.0 or > binutils-2.31; I can't comment on GDB usage, because I've never built > it. AFAICT, the bfd and opcodes directories use this, and it comes from bfd/configure.host. So yes, you won't see it in GCC, but you should see it when building Binutils (but I didn't yet try building Binutils since upgrading the MinGW runtime). > However, __USE_MINGW_FSEEK is another feature test macro which > really shouldn't be visible outside of MinGW.org source code, and the > case for not deprecating it is even weaker ... how many of those > projects which abuse it actually deliver Win9x compatible code today, > anyway? Well, we do want MinGW Binutils to work on Windows 9X, don't we? > Those that do should *really* be defining _WIN32_WINDOWS, which > implicitly enables the __USE_MINGW_FSEEK feature. My problem with _WIN32_WINDOWS is that it appears in a dozen places in our w32api headers, and just analyzing its impact is a serious job. By contrast, __USE_MINGW_FSEEK is a much more focused knob.
Fork