RFC: Enforcing Bounds Safety in C (-fbounds-safety)

[rapidsna]

@AaronBallman

Structures in C don’t have the notion of a “this” pointer, so members cannot refer to other members even when the order would otherwise allow for it without any late parsing: Compiler Explorer This has caused us problems in the past: Thread Safety Analysis “guarded_by” attribute doesn’t work for struct fields in C code · Issue #20777 · llvm/llvm-project · GitHub and might be more involved than it seems at first (it certainly forges a new path forward for C).

Right, that is a great insight. In the implementation, we’ve added a name lookup for struct members referred to by attributes within the struct’s scope. The name lookup is performed after parsing the struct body, ensuring the field declarations of the same struct are always seen first (not a global declaration of the same name). Another challenge was creating count expressions from struct fields (e.g., __counted_by(n+1) in the example below) without instantiation and without the notion of this in C. This means that the expressions won’t have a base required to create MemberExpr . Therefore, we had to create a DeclRef directly referring to the struct field to represent the expression passed to the bounds annotations, which isn’t something allowed in C. I envision this as an extended behavior limited to expressions, passed to attributes only. It should be generally beneficial for other attributes that require more expressiveness from C, such as the guarded_by attribute you mentioned.

struct S {
  int n;
  // Allowed: Counted by a member variable
  int *__counted_by(n+1) ptr;
};

@AaronBallman

We’ll know whether the committee has strong feelings by Jun 28 (the meetings end on the 27th and we effectively have to process all the national body comments), so we should have at least an idea of the committee sentiment reasonably soon.

@AaronBallman

I would be okay with experimenting in this space under a feature flag once we know what direction WG14 seems most interested in.

Thank you! We will wait until we will have better understanding on the direction.

@AaronBallman

I would like to keep the two extensions under separate flags as they are orthogonal features (even if related). The late parsing feature means we could support thread safety annotations in C with less awkward syntax and we could also support some more complex declarations involving multi-dimensional arrays that are bounded by later parameters, etc. So it stands on its own as an extension outside of bounds safety (which could also make use of it).

Yes, this makes a lot of sense. We will keep the late parsing logic in a separate flag.

@AaronBallman

Ah, good to know, thank you! By “simple reference to a declaration”, will that involve member accesses? e.g.,

struct S { int n; };
void func(struct S s, int * __counted_by(s.n) array);

or just id expressions?

This will only involve id expressions. Member accesses will not be allowed.