These functions don't depend on the C++ runtime and therefore belong to
CRunnerUtils. Clean up the macros on the way as _MSC_VER indicates the
compiler, not the platform, which is indicated by _WIN32 and will be
present when, e.g., compiling with minGW.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I was unsure where to put those functions inside the runtime library, so it's perfectly fine for me to move them.
I'm unsure about the _WIN32 macro though, the usage of _MSC_VER was caused by the fact that MSVC's implementation of the standard library doesn't provide the aligned_alloc function, despite it being part of the standard. Instead, it provides an _aligned_malloc function. Moreover, MSVC also requires the pointers obtained through _aligned_malloc to be deallocated through _aligned_free, and not free (it doesn't impact the previous reasoning, but better to make it known)
Yes, that wouldn't hurt. I feel like the _WIN32 macro alone, though, would cause problems.
I understand that the MSVC macro is not the best in term of maintenability, but unfortunately this is the situation. Here is a link to the official docs for what regards _aligned_malloc and _aligned_free: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/aligned-malloc
Side question, as these are my first times dealing with Phabricator: where do I find the option to accept the revision when I'm among the reviewers?
FWIW, from the mingw point of view, this patch seems fine - mingw doesn’t yet provide the standard aligned_alloc either, but _aligned_malloc can be used, just like with MSVC. So therefore, using _WIN32 for the ifdef seems fine.