PSRWLOCK and PCONDITION_VARIABLE types are defined to PVOID instead of
pointers to forward-declared structs. Define internal typedefs and use
cast_ptr to automatically cast to the type used in Windows SDK.
GetProcAddress returns a pointer to some function. It can return
pointers to different functions, so it has to return something that is
suitable to store any pointer to function. Microsoft chose FARPROC,
which is int (WINAPI *)() on 32-bit Windows. The user is supposed to
know the signature of the function he requests and perform a cast
(which is a nop on this platform). The result is a pointer to function
with the required signature, which is bitwise equal to what
GetProcAddress returned. However, gcc >= 8 warns about that.
Add an overload with a template parameter to do the cast inside
the function and suppress the warning there.
This should silence -Wconversion warnings with gcc caused by integral
promotion that happend in the MAKELANGID macro implementation.
Also, simplified casts in our custom implementation of MAKELANGID_
function. Use C++ static_casts instead of C-style casts.
Closes https://github.com/boostorg/winapi/pull/88.
This header is already included by Boost.Predef, but since we're
directly using macros defined in it, we better explicitly include
it ourselves and not rely on Boost.Predef implementation details.
This allows to use any compatible types with INTERLOCKED_* macros, not just
the ones strictly matching the particular implementation of the intrinsics.
In particular, this fixes compilation for Cygwin64, which is an LP64 target,
meaning that long is 64-bit and _Interlocked* intrinsics use a different
integer type for its 32-bit integer arguments.
Additionally, enable use of intrin.h on Cygwin (32-bit).
The test has been updated to explicitly use 32-bit integer arguments.
There is a macro conflict for _InterlockedExchangePointer between intrin.h from
MSVC-12 and winnt.h from Windows SDK 8.1, which causes compilation failures.
This warning is not supposed to appear for global constants, however gcc 5.3
from MinGW spams this warning, at least for the invalid_handle_value constant.
Therefore we disable this warning for all constants declared in Boost.WinAPI.
This commit incorporates some of the changes made to
boost/smart_ptr/detail/sp_interlocked.hpp by Peter Dimov, namely:
- Define an internal config macro BOOST_INTERLOCKED_HAS_INTRIN_H when
the compiler is known to have a useful intrin.h header.
- Use this macro to select the common implementation based on intrin.h.
- Removed MinGW-w64 branch of implementation as it is now covered by
the common branch based on intrin.h.
- Added detection of clang-cl, a new MSVC pretender. The compiler is
assumed to have support for intrin.h.
- Added a separate branch for Windows CE >=6, with differently named
interlocked functions. No way to test this and no idea if this is
correct.
- For MSVC 8 and 9 don't use intrin.h as it reportedly conflicts
with <utility>. On these compilers we will declare the intrinsics
ourselves.
These macros conflict with the same named macros from Windows SDK and generate
warnings. Downstream libraries were ported to Boost.WinAPI replacement macros.
These macros may clash with macros defined by Windows SDK and generate warnings.
Downstream libraries need to be ported to Boost.WinAPI replacements and then
these definitions can be removed.
The compiler on Cygwin 64 does not define _WIN64. Instead, the macro is
defined in the private header. Without the macro we fail to detect 64-bit
Windows target and define basic types incorrectly. Include the private
header for now; we may switch to our private macro for this purpose
eventually.
Also avoid using boost/cstdint.hpp to define basic integer types as in
case of Cygwin 64, an LP64 platform, uint64_t and ULONGLONG are different
types.
