irwir
irwir
> the prototype has been unchanged for at least 13 years and never has been a problem. For the last 6 years it was SOCKET; the link to the commit...
> inconsistency between the `simpleUPnPcommand` prototype in the .c and in the .h The first argument is used as a socket, hence it must be `SOCKET`. Troubles began when directory...
> In fact the 1st argument should be removed. It is not used internally in miniupnpc. Things may change in next versions, but this is the current code: https://github.com/miniupnp/miniupnp/blob/a71563298745bb94bdc71b1493db3c08a532acb6/miniupnpc/src/miniupnpc.c#L200-L203 `connecthostport`...
The suggestion would be to add local `SOCKET s;` variable, and remove condition check at line 200. Then the first parameter could be removed. Othewise, the parameter should be renamed,...
> that is exactly what this PR is doing : declaring s as `SOCKET`. It does, but in a strange way. First, explicit use of the 1st parameter that might...
Is it necessary to define STL version? If not, the changes could be as short as: ``` #if defined(_MSVC_STL_VERSION) // VS2017 (14.1) and above # define CRYPTOPP_MSSTL #elif defined(_CPPLIB_VER) &&...
> As this code is not needed to fix a compile break with the MSVC compiler but with the Microsoft STL I changed the check to the corresponding STL version...
Have you read carefully the issue 147 referenced in the mentioned PR? The "attempt to unbind clang from others" mostly failed, because on Windows clang is not self-sufficient and works...
> The current logic for enabling or disabling the `CRYPTOPP_ARM_*_AVAILABLE` macros seems wrong OR'ed condition contains a list of known and allowed compilers; otherwise `__ARM_FEATURE_CRYPTO` could be used to force...
> Now after my modification, a known and allowed compiler must be used _and_ `__ARM_FEATURE_CRYPTO` must be set. Incorrect interpretation of code logic. Should cryptopp need a single on/off switch...