https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #22 from Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> --- (In reply to Martin Uecker from comment #20) > > I haven't seen comments on Kees's first example, where "malloc" returns an > > "__alloc_size" hint that's lost when "p" is returned from the function (at > > least in Clang). If that information is kept around, it would expand the > > number > > of bounds checks we could perform. (Kudos if this is currently the case in > > GCC.) > > I think not. But this would not work across TU boundaries anyway. > > https://godbolt.org/z/eW9GT579r It's not that the information is lost in this case, it is just not visible, unlike bug 96503 for example where the information is actually lost. The example above doesn't work because the compiler is instructed to *not* look inside foo; I'd expect something like LTO to work even across TU boundaries whenever possible. There's the external linkage gap, but I don't know if that's a relevant motivation for the kernel. >From the kernel (or distribution builds) perspective, __element_count__ will cover situations where it's not straightforward to propagate sizes, e.g. where the target code is an allocator that itself wants to enforce size constraints on objects it returns, beyond the input size request. This really should have been the way __access__ was implemented, but we tied that attribute to only functions. Would it be a terrible idea to make __element_count__ more general purpose so that it ends up deprecating __access__?
