https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #66 from Alejandro Colomar <alx at kernel dot org> --- (In reply to Kees Cook from comment #65) > (In reply to Alejandro Colomar from comment #64) > > How about having two macros? One that works for non-attributed pointers, > > and other that works for attributed ones. And use the appropriate one for > > each of them. > > > > If you accidentally use the one that uses the builtin, it'll cause a > > compiler error. > > No, that's exactly what I am trying avoid. There should be no additional > work needed beyond adding "counted_by" to the struct. Hmmm, I understand. > > > alloc_no_attribute() would work everywhere, and alloc() only where the > > attribute is used. > > We are actively trying to reduce the number of duplicate APIs. The compiler > has everything it needs to do this without duplicating an API. > > > You could still do this with my approach. And there are less NULL pointers > > around, which would get messy. > > I disagree: all the NULL checks are constant and removed at compile time. I wasn't worried about the run-time performance. I'm worried about the complexity it adds. You're forcing all users of this builtin to do NULL checks before using it. However, if you have compile-time errors, a user that does not have the same needs as the kernel will be able to do the 2 APIs approach. Or even say, one uses the attribute already everywhere (e.g., the kernel in a near future where all code has been adapted), so has a single API, which uses the builtin, and they want to make sure no new code is added that doesn't have the attribute. A compiler error would easily show bugs like that, while NULL checks would just silence it. So, an alternative, which would support both my and your constraints would be to request Clang to implement __builtin_has_attribute() *and* have a compiler error if __builtin_set_counted_by is used on a pointer that doesn't have it, I think. > There is literally no benefit at all to having 2 APIs. :)
