5 ms·
You're right. Just compiled the following program with clang from Xcode 14 (Apple clang version 14.0.0 (clang-1400.0.29.102)) without issue. #include <stdio.
by davidbalbert 4y ago
You're right. Just compiled the following program with clang from Xcode 14 (Apple clang version 14.0.0 (clang-1400.0.29.102)) without issue.
#include <stdio.h>
struct foo {
uintptr_t p __attribute__((xnu_usage_semantics("pointer")));
};
int main() {
struct foo f = { 100 };
printf("%lu\n", f.p);
return 0;
}
Doesn't seem -Wxnu-typed-allocators (which I forgot to mention above) is present in my version. Didn't test the others.
I also just realized that the latest tagged release of https://github.com/apple-oss-distributions/clang https://github.com/apple-oss-distributions/clang is 800.0.38, my clang is reporting 1400.0.29.102. Is Apple no longer releasing the source for their compilers?
- MBCook 4y agoThe article sounded to me like Apple had a private fork with extra tooling to help with their kernel work.
- cbsmith 4y agoHeh... and it was just a few weeks ago I was assured that all of the platform internals were fully open sourced. ;-)
- pjmlp 4y agoI doubt that they have opened the custom C compiler used in iBoot for example. https://support.apple.com/guide/security/memory-safe-iboot-implementation-sec30d8d9ec1/web https://support.apple.com/guide/security/memory-safe-iboot-i...
- saagarjha 4y agoThey have not.
- roblabla 4y agoA lot of the internals are, but certainly not all. And they always lag behind with what is currently released, sometimes by several months.
- cbsmith 4y agoIt's funny, that's pretty much what I said...
- saagarjha 4y agoThe clang that ships in Xcode uses fake version numbers, but yes, some of it remains proprietary.
- pjmlp 4y agoApple never did release everything that their compilers do, that is why cppreference has a column for Apple's clang, and why watchOS can use bitcode as binary format, even though the official LLVM bitcode isn't stable.