mosra/corrade

Windows: inconsistent redefinition of _aligned_malloc

pezcode opened this issue ยท 3 comments

I'm seeing this warning with MSVC and Windows SDK 10.0.19041.0:

Corrade\Utility\Memory.h(50,57): warning C4565: '_aligned_malloc': redefinition; the symbol was previously declared with __declspec(restrict)
2>Corrade\Utility\Memory.h(50,57): warning C4273: '_aligned_malloc': inconsistent dll linkage
2>Windows Kits\10\Include\10.0.19041.0\ucrt\corecrt_malloc.h(154,15): message : see previous definition of '_aligned_malloc'
2>Corrade\Utility\Memory.h(51,45): warning C4273: '_aligned_free': inconsistent dll linkage
2>Windows Kits\10\Include\10.0.19041.0\ucrt\corecrt_malloc.h(148,14): message : see previous definition of '_aligned_free'

It works fine, but it's a scary-looking warning ๐Ÿ‘€

Slapping __declspec(restrict) onto the function definitions when compiling for MSVC should be fine but it feels messy. How bad is the <malloc.h> include, really?

mosra commented

Yep, this bothers me as well ๐Ÿ˜…

Oh, it's __declspec(restrict)? Then it should be fine to put that there. I can't read, I thought it was __declspec(dllimport) and such, meaning I'd have to do detection whether static or dynamic runtime is used, using the right flag, inevitably running into more problems...

I have a rule to never include anything from Windows in any public header, because then, if your project doesn't define all the NOMINMAX, LEAN_MEAN_LEAN_EXTRA_LEAN_MEAN etc macro, you get stuff like #define interface struct and it's not great. X11 includes are the same, also banned from public headers. An alternative solution I was considering was to add Memory.cpp and chuck the #include <malloc.h> in there, but since that's one more indirection and exported symbol I'm not so sure about the tradeoff.

Actually, let me first check what <malloc.h> has on Windows. Since I don't see a "sanitized" version of this header in https://github.com/Leandros/WindowsHModular, it's probably not so bad after all...

mosra commented

Fixed in d3f4a0c -- the Windows <malloc.h> doesn't seem to have that much cruft, after all.

Thank you ๐Ÿ™‡