RFC: Bounds Safety in C Syntax Compatibility with GCC

[void]

@kees

The prototype for calc_counted_by would be internally declared as:

static size_t __pure calc_counted_by(struct foo *this);

i.e. there would be no need for the early declaration. The return value is always going to be size_t, so that never changes, it’s always going to be pure, and it’s always going to take a pointer to the surrounding struct as the one and only argument. There’s no good reason to make the user repeat all this information – we can simple define it as having the given prototype.

Good point. One question, is there any reason for the return value to be anything other than size_t?

@rapidsna

For the sake of further discussions about this approach, I’m curious how you would like to generalize it for parameters, i.e., expressions in annotations for function parameters, for which names are the function scope.

void foo(int *__counted_by(*outCount) ptr, int *outCount) {
  // ...
  *outCount = countOfActuallyUsedElements;
}

Nested functions? (Just kidding )

This is a bit off the top of my head as I haven’t thought about this situation too heavily. Unfortunately, some ideas require changes to C (at the very least).

@uecker previously suggested using a “forward parameter declaration” for this.

void foo(int *outCount; int *__counted_by(*outCount) ptr, int *outCount) ...

It’s similar to the forward declaration syntax we suggested further up, but it doesn’t involve changing the expression in __counted_by. It does involve changing the language, but it apparently has some support within the working group. @uecker could expand on this further, if he’s still in favor of the syntax.

If we didn’t want to go that route, perhaps we could use something along the lines of a lambda expression. I know C doesn’t have those, so this also requires a change in the base language. Though Clang supports “blocks”, which are similar to lambdas. I’m not sure whether GCC has a lambda-like feature.

// C++ example as I don't know the 'blocks' syntax.
void foo(int * __counted_by(update_count) ptr, int *outCount) {
  auto update_count = [&](void) -> size_t { return *outCount; };
  // ...
}

Like I said, these are off the top of my head, so they will have drawbacks.

@rapidsna

Also, what do you think about using __counted_by(id), which either accepting a variable or a function name, instead of having a separate attribute name.

I like it for its simplicity, but it might lead to some issues. For instance, if we go with @kees’s suggestion of synthesizing a function prototype if one doesn’t exist and id hasn’t been encountered before, how do we differentiate between id as a variable or function? Also, what if id is both a field and a function?

int foo();

struct x {
    int __counted_by(foo) *bar;
    int foo;
};

Using __counted_by_func makes it more explicit.

@rapidsna

Fwiw, I’d personally prefer the prototype to be static size_t __pure calc_counted_by(struct foo *this); rather than a void * as @kees suggested above.

Yeah, me too. I suggested void * due to the need to forward declare the function prototype, but if we don’t have to do that then there’s no need.

@AaronBallman

Thank you for sharing alternative ideas! My primary concerns with your new approach are:

• While it solves the problem for structures, it doesn’t scale to parameter lists, at least that I see.

See what I wrote above for @rapidsna’s similar question.

@AaronBallman

• I think the analysis of what the count is becomes much more complex because of the ease at which you can have arbitrary expressions within the function body. I suspect diagnosing “incorrect” counted by functions will be a challenge.

I know and I wasn’t trying to minimize the impact this feature would have. I don’t have much in the way of a good answer to this as, like I said, I haven’t seen the code you’re using to perform the analyses. Am I correct that it’s at least possible to get the information from the AST when needed?

@AaronBallman

• Readability of the code is somewhat reduced because now you have to mentally jump into a function body (which may be defined in a different file) in order to understand the counting semantics.

One reason I want the functions to be static (and hopefully inline) is to keep it close to the structure it’s associated with, thus removing, or at least limiting, this worry. We wouldn’t be able to stop someone from doing something like:

// some_header.h
struct b;
static size_t __pure inline count_for_struct_b(struct b *ptr) {
 // ...
}

// some_other_header.h
#include "somewhere/in/limbo/some_header.h"

struct b {
  int * __counted_by(count_for_struct_b) buf;
};

(This is a degenerate case worthy of the IOCCC.)

Making it static should ensure that the function is within the same translation unit as the struct’s definition and usage.

@AaronBallman

One question I have relates to what Vlad suggested here:

I think there’s an alternative approach to the problem that forward declaration are trying to solve. For cases when counter follows the pointer, we can put the attribute on the counter, avoiding the problem of referencing something we don’t yet know about altogether: struct S {} a; struct b { char* buf; char** buf_2d; __typeof(a) c; // no forward decl of int a - no issues here int __counts(buf) __counts(buf_2d) a; // if one counter counts two pointers, use two attributes i…

While I’m not excited about the idea of duplicating attributes, it does have some appeal. It solves the problem of needing a forward declaration of any kind because the attributes are symmetrical. It also increases the expressiveness of the code because it may be more natural to say “this field is the count for these other four fields” than to say “this field is counted by that field” four times. And it requires no late parsing or modifications to the standard.

The downside is: now you have two attributes any time you want this property. That impacts things like bounds safety attribute and thread safety attributes, so I expect this means adding 10-20 new attributes. But is that significantly worse than any of the other options we’ve come up with?

If we wanted to go that route (placing the attribute somewhere other than the fields / variables), I would suggest the alternative @hnrklssn wrote (in response to __counts):

@hnrklssn

I think if you want to go that direction, it’d have to be something like:

struct S {
  char *buf;
  int size;
  int offset;
} __counted_by(size - offset, buf);

However, this doesn’t easily extend to parameters. And I agree with the downsides he mentions in the same post.