[cfe-dev] Latest clang and dllimport

[Edward Diener]

On 7/21/2015 6:43 PM, Reid Kleckner wrote:
> I don't think we have any feature test flags for diagnostic changes.
>
> It sounds like the general problem is that two headers declare parts of
> the win32 API because windows.h is too much of a header dependence.
> Boost also isn't sure sure whether windows.h, from mingw or Microsoft,
> is using dllimport or not. Past versions of mingw have been
> inconsistent, so you can't just always declare it dllimport, like it
> should be.
>
> I'm starting to feel like we should just downgrade this to a warning for
> free functions. We already make it a warning in other cases. Very few
> programs rely on function pointer identity, but global variable identity
> is often important.

Please do change this if it is possible for clang.

Let me argue the case as a clang user. Neither gcc or vc++ on Windows 
requires the sort of attribute matching with imported Windows API 
functions that clang requires. In other words if a Windows API has 
__declspec(dllimport) as part of the declaration of a function and the 
end-user separately declares that function without the 
__declspec(dllimport), it is not an error with gcc or vc++.

By enforcing a matching of this __declspec(dllimport) you are making 
code match whatever the particular Windows API header files specify. But 
the various Windows implementations are different so now the end-user 
has to figure out which Windows implementation is being used at 
compile-time and manipulate his declaration accordingly. In particular 
mingw never used any __declspec(dllimport) whereas mingw-64 appears to 
always use it. The official Microsoft header files also use it.  I have 
not used cygwin but that is yet another case.

You may ask why any end-user is declaring a Windows API function instead 
of just including windows.h. For Boost the answer is all the header file 
dependencies that windows.h brings in, as well as the non C++-isms and 
poor C++-isms which the windows header files are famous for and for 
which code often has to find workarounds ( the common macro names are 
one example of these sorts of problems ). So a Boost library will often 
try not to include windows.h when it is using very few Windows API 
functions.

By enforciong this strict function declaration matching clang is making 
it much harder to declare Windows API functionality than it need be.


>
> Sound reasonable?
>
> On Tue, Jul 21, 2015 at 12:36 PM, Edward Diener
> <eldlistmailingz at tropicsoft.com
> <mailto:eldlistmailingz at tropicsoft.com>> wrote:
>
>     In the latest clang built from source, if a function is mismatched
>     as to a difference in dllimport attributes clang produces an error.
>     As in:
>
>     C:\Utilities\mingw-w64\i686-5.1.0-posix-dwarf-rt_v4-rev0\mingw32\i686-w64-mingw32\include\synchapi.h:127:26:
>     error: redeclaration of 'Sleep' cannot add 'dllimport' attribute
>        WINBASEAPI VOID WINAPI Sleep (DWORD dwMilliseconds);
>                               ^
>     ..\..\..\boost/smart_ptr/detail/yield_k.hpp:67:29: note: previous
>     declaration is here
>        extern "C" void __stdcall Sleep( unsigned long ms );
>
>     Changing the latter to:
>
>        extern "C" __declspec(dllimport) void __stdcall Sleep( unsigned
>     long ms );
>
>     fixes the problem for clang.
>
>     Earlier versions of clang ( 3.4.1, 3.5.2, 3.6.1 ) did not have this
>     problem. Is there a __has_feature or __has_extension that I can use
>     to test this change in the latest clang ? The previous versions are
>     also happy with the __declspec(dllimport) added in the declaration
>     so even without a __has_feature or __has_extension I can just test
>     for clang on Windows, but I like to be as precise as possible in
>     Boost code.
>
>
>
>
>
>     _______________________________________________
>     cfe-dev mailing list
>     cfe-dev at cs.uiuc.edu
>     <mailto:cfe-dev at cs.uiuc.edu>
>     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>