[PATCH] D125919: Drop qualifiers from return types in C (DR423)

John McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Fri Jun 3 10:22:20 PDT 2022


rjmccall added a comment.

Are you now arguing that C was wrong to drop qualifiers in return types and so we shouldn't implement that rule, or...?  Because your argument is much broader than just `_Atomic`.

I don't understand the analogy you're making to `_Complex` at all.  Values of type `_Complex T` are fundamentally different from values of type `T`.  `_Imaginary` (which Clang does not implement) is more like a semantic recast of `T`, but that recast is critically important, and in no way does it act like a qualifier.  Meanwhile, `_Atomic` is only meaningful at the top level on l-values, exactly like a qualifier, and you can assign non-atomic r-values into an atomic l-value and read them back out again, just like a qualifier.

Now, the standard has chosen not to talk about `_Atomic` as a qualifier, I assume because there's a fair number of rules in the standard that assume that qualifiers can be freely added to pointers and don't change layout and so on, none of which apply to `_Atomic`.  But those rules also don't apply to a large number of other extended qualifiers, like address spaces and the ARC ownership qualifiers and `__ptrauth`, and the committee should probably just come to terms with the fact that it's the relative easy-come-easy-go nature of the CVR qualifiers which is the special case.

I see absolutely no reason why anybody should ever want to declare a function as `_Atomic(int) func(void);`, and if the C and c++ committees decide to break people who aren't just doing it but are doing it inconsistently, they're doing the world a service.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125919/new/

https://reviews.llvm.org/D125919



More information about the cfe-commits mailing list