Hi,
On Fri, 29 Jul 2022, Jean-Michaël Celerier wrote:
As reported on Github:
I don't think we officially use the github repo for issues - (although the
sourceforge issue tracker also is mostly unmantained), so I guess this
mailing list currently is the best place to discuss such issues - so I'm
following up on the issues here:
====== issue 1 =======
https://github.com/mingw-w64/mingw-w64/issues/11
#if __MINGW_GNUC_PREREQ (3, 3)
#define __MINGW_NOTHROW __attribute__ ((__nothrow__))
#elif __MINGW_MSC_PREREQ(12, 0) && defined (__cplusplus)
#define __MINGW_NOTHROW __declspec(nothrow)
#else
#define __MINGW_NOTHROW
#endif
if compiling with clang++ -fms-compatibility (which defines _MSC_VER), this
seems to fail. May I suggest a change into:
#elif __MINGW_MSC_PREREQ(12, 0) && defined (__cplusplus) &&
!defined(__clang__)
for the second branch ?
I think you need to give a bit more details on this issue - what works
except for this particular issue you're fixing, and exactly what issue are
you running into with __declspec(nothrow).
Building code with -fms-extensions is done somewhat commonly (which
enables some but not all MS specific syntax details), while I think
-fms-compatibility is much more rare. Apparently this command line option
is Clang specific too.
Just building code that includes e.g. stdio.h with -fms-compatibility
seems to fail with a large number of errors, so this doesn't seem like the
only issue needed to be fixed to make that mode usable?
That said, if this is part of a larger effort to make that mode usable, it
could be considered, but I'd like to understand the whole context here.
compiling with clang++ -fms-compatibility (which defines _MSC_VER)
This doesn't seem to be true? I tried to compare what predefined defines
are set and unset by this change, by doing this:
$ clang -target x86_64-w64-mingw32 -E -dM - < /dev/null > defs-orig
$ clang -target x86_64-w64-mingw32 -E -dM -fms-compatibility - < /dev/null >
defs-mscompat
$ diff -u defs-orig defs-mscompat
Doing this does seem to stop defining __GNUC__, but it doesn't seem to
define _MSC_VER. That leaves the state of the compiler quite uncertain for
system headers to pick what features to use, as it doesn't really match
any known configuration.
But you say that clang does define _MSC_VER somehow, and then fails to use
__declspec(nothrow) (which would be a MSVC specific construct). I think
that if a compiler does define _MSC_VER, it should also support handling
MSVC style attributes like this one - I don't think it's feasible to
litter all code that checks _MSC_VER (or __MINGW_MSC_PREREQ in this case)
with checks for !defined(__clang__), because that also breaks proper use
of Clang in regular MSVC mode.
(Mingw-w64 headers don't practically support being compiled by Clang
in regular MSVC mode, but that's at least a clear goal that one
could consider supporting if someone would send patches for it.)
====== issue 2 =======
https://github.com/mingw-w64/mingw-w64/issues/9
Here:
https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-headers/include/ws2tcpip.h#L287
typedef struct addrinfoExW {
int ai_flags;
int ai_family;
int ai_socktype;
int ai_protocol;
size_t ai_addrlen;
LPCWSTR ai_canonname;
struct sockaddr *ai_addr;
void *ai_blob;
size_t ai_bloblen;
LPGUID ai_provider;
struct addrinfoexW *ai_next;
} ADDRINFOEXW, *PADDRINFOEXW;
the ai_next field is struct addrinfoexW *ai_next;. It should be struct
addrinfoExW *ai_next; (notice the captial E) to match the class name, here
it introduces a new struct name...
addrinfoExA defined just above has the same issue.
Thanks, this sounds like a simple and clear cut issue to me. Can you send
a git format-patch style patch to this list, so we can review and consider
it for merging?
====== issue 3 =====
https://github.com/mingw-w64/mingw-w64/issues/8
I'm trying to build a software under mingw-w64 which uses:
GetAddrInfoExCancel
GetAddrInfoExOverlappedResult
which do not seem to be available in the headers. If someone can give me a
rough outline of the procedure I can try to add them in a PR.
Generally, find out their signature (from e.g. official docs) and
handwrite a patch that adds those declarations to the right place in our
headers (note, it might be important to make sure that it's within the
right kind of "#if _WIN32_WINNT >= 0x..." condition, so that code that
checks for its availability doesn't end up accidentally relying on it).
Note that you mustn't do a direct copy-paste, to avoid risk of copyright
infringment, as the mingw-w64 headers are distributable under its own
license.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
