Closed kivadiu closed 6 years ago
Hi, thanks for reporting this.
It seems there is yet an issue when we moved to winapi. @Lastique, do you have any idea of c-what can be done?
The only thing I can suggest is to silence or work around the warning. The code is correct, AFAICS, this is the intended usage pattern of GetProcAddress
, which indeed requires a cast between potentially different types of function pointers.
It is weird to cast between "potentially different types of function pointers", isn't it? What could be the expected result of such a kind of casts?
Not so weird, not really. 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.
This may not be a well defined standard C++, but, well, that's now 95% of system programming works.
So it's really harmless. I'm happy to hear that.
Ok, I would accept a PR that silent this warning.
Sorry, I don't have a Windows platform to test it.
Any idea why PR #227 failed some tests in appveyor? It seems completely unrelated to my patch.
See #227
While building 1.68.0 beta 1 on x86_64 cross-compiling to Windows 32 bits with mingw-w64 + g++ 8.2.0, I get the following warning: