3 ms·

In what sense is __counted_by "standardized"? And is it really worth deviating from what's already there?

olliej 3y ago
Sorry that was really badly phrased. GCC and Clang have a standard syntax for attributes, which is what this feature uses. Moreover the position semantics of the __attribute__ syntax matches the positional semantics of the standardized C++ attribute syntax, which is (fingers crossed) finally being picked up in C23. So with that mea culpa let's address the rest. __counted_by is obviously not standardized - this is an RFC for clang, let alone a spec proposal. __counted_by is a macro that expands to: __attribute__((__counted_by__(T))) Which is the standard syntax for all attributes in clang and gcc. So the question is why the position is different from under SAL. SAL considers the bounds of a pointer to be a feature of the declaration, not the type. This RFC consider pointer bounds to be an attribute of the type itself. Because of that, the syntax of the attribute needs to be in the location for type attributes. You might reasonably respond with "a one off match of this other syntax would have been ok", but the SAL syntax also means that you can only specify one set of bounds per declaration. By having bounds be an attribute of the type you can specify the bounds at each level of indirection in a declaration, so you can have something like: void dump_string_list(int N, const char * __null_terminated * __counted_by(N) thing); The other part is that this RFC also allows for opt in wide pointers so you can do void something_else(int N, int * __indexable * __counted_by(N) thing); Which would presumably not be usable for an existing API, but for internal logic that isn't subject to ABI constraints would allow the adoption of bounds safety without significant source changes. It also highlights the impact on syntactic consistency of having this be an attribute of the type. Now, given the necessary positional difference, reusing the same token as used for MS's SAL would make these incompatible, so code bases would need to use different macro names for each anyway. Finally, if it was considered really valuable, then someone could implement the same implicit adoption that occurs when SAL attributes are present, as already occurs if you do something like void f(int N, int buffer[N]) while retaining the significantly more powerful and flexible attributes provided by this RFC.

Sorry that was really badly phrased. GCC and Clang have a standard syntax for attributes, which is what this feature uses. Moreover the position semantics of the __attribute__ syntax matches the positional semantics of the standardized C++ attribute syntax, which is (fingers crossed) finally being picked up in C23. So with that mea culpa let's address the rest. __counted_by is obviously not standardized - this is an RFC for clang, let alone a spec proposal. __counted_by is a macro that expands to: __attribute__((__counted_by__(T))) Which is the standard syntax for all attributes in clang and gcc. So the question is why the position is different from under SAL. SAL considers the bounds of a pointer to be a feature of the declaration, not the type. This RFC consider pointer bounds to be an attribute of the type itself. Because of that, the syntax of the attribute needs to be in the location for type attributes. You might reasonably respond with "a one off match of this other syntax would have been ok", but the SAL syntax also means that you can only specify one set of bounds per declaration. By having bounds be an attribute of the type you can specify the bounds at each level of indirection in a declaration, so you can have something like: void dump_string_list(int N, const char * __null_terminated * __counted_by(N) thing); The other part is that this RFC also allows for opt in wide pointers so you can do void something_else(int N, int * __indexable * __counted_by(N) thing); Which would presumably not be usable for an existing API, but for internal logic that isn't subject to ABI constraints would allow the adoption of bounds safety without significant source changes. It also highlights the impact on syntactic consistency of having this be an attribute of the type. Now, given the necessary positional difference, reusing the same token as used for MS's SAL would make these incompatible, so code bases would need to use different macro names for each anyway. Finally, if it was considered really valuable, then someone could implement the same implicit adoption that occurs when SAL attributes are present, as already occurs if you do something like void f(int N, int buffer[N]) while retaining the significantly more powerful and flexible attributes provided by this RFC.