Am Sonntag, dem 08.09.2024 um 02:26 -0700 schrieb Bill Wendling: > On Sat, Sep 7, 2024 at 12:21 AM Jakub Jelinek <ja...@redhat.com> wrote: > > On Sat, Sep 07, 2024 at 07:50:29AM +0200, Martin Uecker wrote: > > > > 2. Apple's implementation supports expressions in the '__counted_by' > > > > attribute, thus the 'count' may be an R-value that can't have its > > > > address taken. > > > > > > > > [1] > > > > https://discourse.llvm.org/t/rfc-introducing-new-clang-builtin-builtin-get-counted-by/80836/ > > > > > > Yes, this would be a limitation. > > > > But then you really can't return an lvalue either, all you can return is an > > rvalue in that case. So just return a (void*)0 in that case. > > > The builtin will return an r-value regardless. The idea is that if the > counter can't be used as an l-value, we wouldn't add an implicit > r-value -> l-value cast (an internal Clang AST node). In the cases > where it can be used as an l-value, we add the implicit cast. I > imagine GCC has some kind of analogue to that? The '(void *)0' case > could be reserved only for when the builtin is used as an l-value but > the r-value can't be cast as an l-value...
I do not know what a r-value -> l-value cast is or why Clang needs it. I guess it backconverts an r-value which came from a l-value to an lvalue... The issue with returning r-value when the counter expression is not an lvalue referring to a struct member is that the user would also need yet another new mechanism to detect this case at compile-time. Martin
