Keith Marshall
keith****@users*****
Sun Jul 29 05:01:58 JST 2018
On 28/07/18 20:21, Eli Zaretskii wrote: >> From: Keith Marshall <keith****@users*****> >> Date: Sat, 28 Jul 2018 19:40:45 +0100 >> >>> #if !defined _WIN32_WINNT || _WIN32_WINNT < 0x501 >>> # undef _WIN32_WINNT >>> # define _WIN32_WINNT 0x501 >>> #endif >>> #include <winsock2.h> >>> #include <ws2tcpip.h> >>> >>> This used to work with MinGW runtime 3.x, but now fails, evidently >>> because winsock2.h no longer includes windows.h, >> >> Actually, it does, but indirectly via <winsock.h>, with which it now >> shares code which is common to WinSock v1.1 and v2 protocols. > > Hmm... you are right. So the problem happens due to this chain of > events: > > . winsock2.h includes winsock.h > . winsock.h defines __WINSOCK_H_SOURCED__ > . winsock.h then includes winerror.h > . winerror.h sees that __WINSOCK_H_SOURCED__ is defined, and > refrains from defining ERROR_* macros Yes. >>> So I need to include winerror.h before winsock2.h, in order to have >>> those error codes defined. >> >> It shouldn't matter which order you include them; <winsock2.h> first, >> followed by <winerror.h> should work just as well. > > Right. But include it I must, yes? In which case, at least for a > while, a solution such as the one below is the best I can use: > > #if defined __MINGW32_VERSION && __MINGW32_VERSION >= 5000002L > # include <winerror.h> > #endif > #include <winsock2.h> That should work, for versions 5.0.2 and 5.1, (the latter being the current release, as of 2018-02-26). I'll ensure that it becomes redundant, from 5.1.1, (or whatever I call the next release). > Or is there a better/cleaner way out, which doesn't break older w32api > versions (nor MinGW64, which doesn't define __MINGW32_VERSION)? Replace the copy of <winerror.h>, in your $MINGW_ROOT/include, with the attached? >>> Do these programs do something that isn't "kosher" nowadays? What >>> should a program do if it wants to include winsock2.h, but doesn't >>> want to include windows.h before that? Is that allowed? >> >> Yes. In fact, IIRC, it is required for strict MSVC compatibility. >> >> What is less clear cut is: should <winsock2.h>, (and indeed >> <winsock.h>), unconditionally expose all of <winerror.h>, or just those >> definitions which are relevant for the WinSock protocols? > > The problems happen in programs that include winsock2.h, but also need > to handle Windows errors that have nothing to do with sockets. I > think what w32api v5.0.2 does assumes that this combination cannot > happen, but it does, of course. Yes. It may not be strictly "kosher" to assume that including just <winsock2.h>, or <winsock.h>, should be sufficient to expose everything from <winerror.h>, but it seems that historically that did happen. To preserve the status quo... >> On balance, it may be best to just expose all of <winerror.h>, whenever >> it is included > > Agreed. ...the attached replacement <winerror.h> does exactly that. Perhaps you'd like to test it? Does it resolve the issue? -- 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: winerror.h Type: text/x-chdr Size: 112769 bytes Desc: not available Url : https://lists.osdn.me/mailman/archives/mingw-users/attachments/20180728/63880e57/attachment-0001.h -------------- 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/20180728/63880e57/attachment-0001.pgp
Fork