gulrak / filesystem

An implementation of C++17 std::filesystem for C++11 /C++14/C++17/C++20 on Windows, macOS, Linux and FreeBSD.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

gcc 9.2 warning (-Wcast-function-type) on MSYS2

phlptp opened this issue · comments

Describe the bug
warning in gcc 9.2 on MSYS2 environment

C:/msys64/home/phlpt/HELICS/build_gcc/include/helics_cxx/helics/external/filesystem.hpp: In function 'void ghc::filesystem::detail::create_symlink(const ghc::filesystem::path&, const ghc::filesystem::path&, bool, std::error_code&)':
C:/msys64/home/phlpt/HELICS/build_gcc/include/helics_cxx/helics/external/filesystem.hpp:1605:159: warning: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'ghc::filesystem::detail::CreateSymbolicLinkW_fp' {aka 'unsigned char (*)(const wchar_t*, const wchar_t*, long unsigned int)'} [-Wcast-function-type]
 1605 |     static CreateSymbolicLinkW_fp api_call = reinterpret_cast<CreateSymbolicLinkW_fp>(GetProcAddress(GetModuleHandleW(L"kernel32.dll"), "CreateSymbolicLinkW"));
      |                                                                                                                                                               ^

To Reproduce
Detailed steps to reproduce the behavior.

Expected behavior
It would be nice if the code were warning free

Additional context
MSYS2, gcc 9.2 compiler --std=c++14, most warnings turned on.
Tried with the latest release, but that didn't clear up the warning.

Yes it is my goal too, to be warning free, when possible, GCC 9 on MSYS2 is not yet under the CI tested compilers. I'll look into it.

as best as I can tell the most recent commit 73da6e1 does clear up the warning on MSYS2. I am not really familiar with those functions or think we are using them in any way so I can't speak to the correctness. But it does clear up the warning, so that is 👍

Re-updated the fix, as I didn't like that "evil cast" myself. Following the example of other projects to disable the check for these lines as it is a known issue with GetProcAddress and the warning is not helpful in that exceptional context.

Fix released with v1.2.10