[davidbalbert]

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 is 800.0.38, my clang is reporting 1400.0.29.102. Is Apple no longer releasing the source for their compilers?

[saagarjha]

The clang that ships in Xcode uses fake version numbers, but yes, some of it remains proprietary.

[pjmlp]

Apple 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.

[MBCook]

The article sounded to me like Apple had a private fork with extra tooling to help with their kernel work.

[cbsmith]

Heh... and it was just a few weeks ago I was assured that all of the platform internals were fully open sourced. ;-)

[pjmlp]

I doubt that they have opened the custom C compiler used in iBoot for example.

https://support.apple.com/guide/security/memory-safe-iboot-i...

[saagarjha]

They have not.

[roblabla]

A lot of the internals are, but certainly not all. And they always lag behind with what is currently released, sometimes by several months.

[cbsmith]

It's funny, that's pretty much what I said...