ojhunt wrote: > I realize you've got downstream users making use of this additional > qualifier. Can you mention how prevalent the use is?
it's used a bunch in libcxx, libcxxabi, libunwind, compiler-rt and a few other places. We can obviously use a macro to wrap this, but we need to have a way to distinguish compilers that permit __ptrauth on non-pointers, and those that require __ptrauth_restricted_intptr. There is a feature flag check available for __ptrauth_restricted_intptr so you could make an argument for pretending clang has always supported __ptrauth on integer types and have code assume that works, though that obviously causes problems where people might introduce __ptrauth qualified integers that will fail to build with older apple clangs due to the different qualifiers. Again this can be mitigated by ifdefs, e.g. ```cpp #if !__has_feature(__ptrauth_restricted_intptr) #define __ptrauth_restricted_intptr(...) __ptrauth(__VA_ARGS__) #endif ``` Which in principle could go in the general `ptrauth.h` header > Do you have evidence that the second qualifier catches issues for users, or > was this mostly a theoretical problem that you wanted to head off before > users ran into it? The latter, the raw __ptrauth qualifier never applied to non-pointer types so there was never the opportunity for it cause it problem. It _does_ mean there's work required to ensure the correct spelling later on (during debugging, etc) which obviously goes away if they have the same spelling, but that going away would result in (assuming an approximation of the above) the displayed type not matching the type as written in the source, and that never happens anywhere else :D https://github.com/llvm/llvm-project/pull/137580 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
