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.
* Make the library modular usable.
* Switch to library requirements instead of source. As source puts extra source in install targets.
* Add requires-b2 check to top-level build file.
* Bump B2 require to 5.2
* Change all <source> references to <library>.
* Update copyright dates.
* Fix glob of tests.
* Move inter-lib dependencies to a project variable and into the build targets.
This allows users to specify BOOST_USE_WINAPI_VERSION in the CMake command
line to select the Windows version for Boost to target.
Requested in https://github.com/boostorg/cmake/issues/63.
It appears that Cygwin and Cygwin64 installations on AppVeyor CI are
outdated and do not provide Windows 10 APIs. A more recent version
installed locally does support Windows 10 and passes tests.
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.
