OK, I guess no one else wants to express an opinion on this, so i went with this one. Real-world code may have some problems down the road, but nothing that can’t be fixed.
Sadly, the world is not so simple it seems. Let me tell you a bitter tale of sorrow and tears.
We started deploying this internally, and found code that broke. That wasn’t too surprising. Then we found out why. The code was “correct”. It included <stdlib.h> just like it should:
#include <pmmintrin.h>
#include <stdlib.h>
or some such. Seems fine? It would be on a mac. But not on Linux. Oh no. Our fearless leaders have declared that they don’t see any problem defining libc functions like this:
#ifdef cplusplus
void *malloc(size_t size) throw();
#else
…
#endif
Yes, that’s an exception specifier on a C malloc function. Apparently this optimizes something for GCC, but sadly it’s utterly and completely non-conforming.
Now we get really interesting, because of course C allows (and many people do) just declaring the malloc function directly rather than adding a header file. That’s great, but then you have to some how intuit whether or not your favorite standard library has broken their declaration in this way, or you get conflicting declarations of the function.
Ok, we can deal with this much. Clang has an egregious hack that will merge these specifiers and accept re-declarations missing them when the original declaration comes from within a system header. So we should be good. Look back up at the includes I mentioned, now back to me. The includes pull in mm_malloc.h first, then stdlib.h. So the first declaration doesn’t have the specifier, and the second one does.
I have no idea what the best way to solve this is. We could extend the egregious hack to allow the reverse ordering, or we could add the stdlib.h include in mm_malloc only wwhen in a hosted environment. Thoughts?