> On Jul 24, 2025, at 3:52 PM, Kees Cook <k...@kernel.org> wrote:
>
> On Thu, Jul 24, 2025 at 04:26:12PM +0000, Aaron Ballman wrote:
>> Ah, apologies, I wasn't clear. My thinking is: we're (Clang folks)
>> going to want it to work in C++ mode because of shared headers. If it
>> works in C++ mode, then we have to figure out what it means with all
>> the various C++ features that are possible, not just the use cases
>
> I am most familiar with C, so I may be missing something here, but if
> -fbounds-safety is intended to be C only, then why not just make it
> unrecognized in C++?
The bounds safety annotations must also be parsable in C++. While C++ can get
bounds checking by using std::span instead of raw pointers, switching to
std::span breaks ABI. Therefore, in many situations, C++ code must continue to
use raw pointers—for example, when interoperating with C code by sharing
headers with C. In such cases, bounds annotations can help close safety gaps in
raw pointers.
Yeoul
> Shared headers don't seem like much of a challenge;
> e.g. Linux uses macros specifically to avoid mixing illegal syntax into
> places where it isn't supported. For example, why can't Clang have:
>
> #if defined(__cplusplus)
> # define __counted_by(ARGS...)
> #else
> # define __counted_by(ARGS...) __attribute__((counted_by(ARGS)))
> #endif
>
> And then use __counted_by() in all the shared headers? C++ uses will
> ignore it, and C uses will apply the attributes.
>
> It seems weird to me that Clang needs to solve how -fbounds-safety works
> with C++ if it's not for _use_ in C++. I feel like I'm missing something
> about features that can't be macro-ified or some ABI issue, but I keep
> coming up empty.
>
> --
> Kees Cook
