Unify code that uses GetProcAddress on Windows

[pps83]

• avoid using CURLX_FUNCTION_CAST, instead dereference destination pointer to FARPROC*
• remove unnecessary function pointer typedefs required for CURLX_FUNCTION_CAST

[pps83]

Note, there were things like APIENTRY vs WINAPI (in case of InitSecurityInterface, LoadLibraryEx, or RtlVerifyVersionInfo). APIENTRY is always defined to WINAPI in the headers.

[jay]

I think there is some reason we are using CURLX_FUNCTION_CAST, probably to avoid some compiler's warnings.

[pps83]

I think there is some reason we are using CURLX_FUNCTION_CAST, probably to avoid some compiler's warnings.

Yes, to cast from FARPROC (return value of GetProcAddress) you need to cast to some function pointer type. This makes it obscure: you have to typedef function pointer type etc. The other way around: if you cast destination function pointer to FARPROC (which is int (WINAPI *)(void)) then you directly assign return value of GetProcAddress without messing with CURLX_FUNCTION_CAST.

[jay]

@MarcelRaad 25d2a1b

[pps83]

@bagder looks like there is an assert in a test (unrelated to the change): https://github.com/curl/curl/actions/runs/7300608761/job/19895602267?pr=12581#step:21:538

FAILED tests/http/test_07_upload.py::TestUpload::test_07_22_upload_parallel_fail[0-h3] - AssertionError: status #0 exitcode: expected 95, got 55

[MarcelRaad]

Unfortunately, this results in strict-aliasing warnings-as-errors on MinGW-w64 with GCC 10 when targeting x64, and so does the recently merged code in a6bbc87#diff-1745e851717837ff181d2de193e6c8b077ec5ea3159a2366740cb66b9c033325. The warning shows up in the autobuilds too:
https://curl.se/dev/log.cgi?id=20231226050249-808232#prob1

[jay]

Unfortunately, this results in strict-aliasing warnings-as-errors on MinGW-w64 with GCC 10 when targeting x64, and so does the recently merged code

What do you recommend? Reject this and change the existing instances to CURLX_FUNCTION_CAST?

[MarcelRaad]

Yes, unless there's another way that doesn't result in new warnings, I'd consistently use CURLX_FUNCTION_CAST instead. Unfortunate that the warning doesn't directly show up in the GitHub CI.

[jay]

Closing in favor of #12581 #12602.

[pps83]

Yes, unless there's another way that doesn't result in new warnings, I'd consistently use CURLX_FUNCTION_CAST instead. Unfortunate that the warning doesn't directly show up in the GitHub CI.

Strange, those warnings should have resulted in warnings as error in CI. IMO, CI should be patched to ensure this happens.