AaronBallman wrote: > > Perhaps silly initial question: why do we need a whole different qualifier > > for this? Why can you not write `__ptrauth uintptr_t foo`? > > Not a silly question, back when first implemented we spent time thinking > about this. > > The concern was basically `T* __ptrauth(...)` can represent all valid > pointers, but `[u]intptr_t __ptrauth(...)` cannot represent all possible > integers, so we wanted the spelling to be very clear that this is not really > an int so making the annotation clear that it restricts what the int can do > seemed valuable. There's also the hypothetical hazard of `SomeTemplateParam > __ptrauth(...)` unexpectedly applying to an integer type so the spelling > difference is a hazard protection there.
Thank you for the explanation! This is a tough situation in some ways. We already went over all the reasons adding a new qualifier is a challenge when adding `__ptrauth`, so there's a very real question of whether the problems solved are sufficiently compelling to be worth having a second qualifier that's basically the same thing as the first. Qualifiers are intended to compose with other types in the type system, so this is a bit like there being two different `const` qualifiers, one for pointers and one for non-pointers. I realize you've got downstream users making use of this additional qualifier. Can you mention how prevalent the use is? 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? I'd like to avoid another RFC, but this is a sufficiently large extension that it may warrant it. My inclination is that this problem can be solved via good diagnostics with the other qualifier and so we don't really need an additional qualifier. https://github.com/llvm/llvm-project/pull/137580 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
