Am Montag, dem 28.07.2025 um 11:18 -0700 schrieb Yeoul Na:
>
>
> > On Jul 28, 2025, at 10:27 AM, Qing Zhao <qing.z...@oracle.com> wrote:
> >
> >
> >
> > > On Jul 26, 2025, at 12:43, Yeoul Na <yeoul...@apple.com> wrote:
> > >
> > >
> > >
> > > > 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.
> >
> > -fbound-safety feature was initially proposed as an C extension, So, it’s
> > natural to make it compatible with C language, not C++.
> > If C++ also need such a feature, then an extension to C++ is needed too.
> > If a consistent syntax for this feature can satisfy both C and C++, that
> > will be ideal.
> > However, if providing such consistent syntax requires major changes to C
> > language,
> > ( a new name lookup scope, and late parsing), it might be a good idea to
> > provide different syntax for C and C++.
>
>
> So the main problem here is when the "same code” will be parsed in both in C
> and C++, which is quite common in practice.
>
> Therefore, we need a way to reasonably write code that works both C and C++.
>
> From my perspective, that means:
>
> 1. The same spelling doesn’t “silently" behave differently in C and C++.
> 2. At least the most common use cases (i.e., __counted_by(peer)) should be
> able to be written the same way in C and C++, without ceremony.
>
> Here is our compromise proposal that meets these requirements, until we get
> blessing from the standard for a more elegant solution:
>
> 1. `__counted_by(member)` keeps working as is: late parsing + name lookup
> finds the member name first
> 2. `__counted_by_expr(expr)` uses a new syntax (e.g., __self), and is not
> allowed to use a name that matches the member name without the new syntax
> even if that would’ve resolved to a
> global variable. Use something like `__global_ref(id)` to disambiguate. This
> rule will prevent the confusion where `__counted_by_expr(id)` and
> `__counted_by(id)` may designate different
> entities.
>
> Here are the examples:
>
> Ex 1)
> constexpr int n = 10;
>
> struct s {
> int *__counted_by(n) ptr; // resolves to member `n`; which matches the
> current behavior
> int n;
> };
>
> Ex 2)
> constexpr int n = 10;
> struct s {
> int *__counted_by_expr(n) ptr; // error: referring to a member name without
> “__self."
> int n;
> };
>
> Ex 3)
> constexpr int n = 10;
> struct s {
> int *__counted_by_expr(__self.n) ptr; // resolves to member `n`
> int n;
> };
>
>
> Ex 4)
> constexpr int n = 10;
> struct s {
> int *__counted_by_expr(__self.n + 1) ptr; // resolves to member `n`
> int n;
> };
>
>
> Ex 5)
> constexpr int n = 10;
> struct s {
> int *__counted_by_expr(__global_ref(n) + 1) ptr; // resolves to global `n`
> int n;
> };
>
>
> Ex 6)
> constexpr int n = 10;
> struct s {
> int *__counted_by_expr(n + 1) ptr; // resolves to global `n`; okay, no
> matching member name
> };
>
> Or in case, people prefer forward declaration inside `__counted_by_expr()`,
> the similar rule can apply to achieve the same goal.
>
Thank you Yeoul!
I think it is a reasonable compromise. I guess a proposal is ready
when nobody likes it but everybody can live with it. Hopefully
we can agree on something nicer later.
Martin
> Yeoul
>
> >
> > Qing
> > >
> > > 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
>
