Bounds-safe interface types are not allowed for local variables. We need to add compiler checking that enforces this.

The compiler needs to validate the type of a bounds-safe type annotation relative to the declared type of the variable, member, or function return value:

• The annotation type must be a checked pointer type.
• It must be identical to the declared type if all occurrences of checked pointer types are replaced with unchecked pointer types.
• The referent type of the annotation type must be ``at least as checked'' as the referent type of the declared type.

We added new rules to the Checked C specification that allow a function name to be cast from its unchecked function pointer type to the corresponding checked function pointer type, where the two function types are compatible

The support for casting from an unchecked function pointer type to the corresponding checked function pointer type should already be there, but we do need to add tests for that.

We need to implement a separate test that ensures that the source is actually a function name and not just a variable with an unchecked function pointer type.

Section 3.1.6 describes storage class-related restrictions on variables used in bounds expressions for bounds declarations. This needs to be implemented.

Parse in-line bounds declaratons for variable declarations.

First of all, thanks a lot for putting this out in the public-domain.

I have a few questions, not sure if this is the best place to ask, but here I go:

A lot more users will directly benefit form this if this is provided as a package through distro-repositories for major OS distributions. So my questions are around how the teams sees this going forward:

• Is the team working with upstream to merge changes back to clang/llvm codebases? If so, what release is being targeted/what timeline?
• If merge-back is not on the cards, what is the long-term plan wrt packaging for various OS distro-flavors? Is the aim to make it available as separate packages on major distros (eg. Debian)?
• If the plan is to have a separate distribution in the long-term, what does this mean for work that happens on Clang/LLVM upstream? Will patches from Clang/LLVM be merged back from time to time? How will the releases be planned?

We added code for serializing and deserializing clang IR with the new checked types. This is necessary to get the code to compile. However, the serialization and deserialization of IR with these types has no tests. We should add tests before people start using compiler functionality that depends on this.

The parser currently looks for return bounds declarations as part of function declarators. They optionally appear after the argument list. For C functions that return constructed types that are complex, it is easy to get confused about this subtlety. One might think that the return bounds declaration appear after the declarator for a function and before the body.

Here is an example of a function that returns an unchecked pointer to 10 element array:

int (*(r31(int arg[10][10])))[10] {
  return arg;
}

If we want to add a bounds interop declaration to this complex declarator, the correct way to write it is:

int (*(r31(int arg[10][10]) : count(10)))[10] {
  return arg;
}

An incorrect way to write this is:

int (*(r31e(int arg[10][10])))[10] : count(10) {
  return arg;
}:

This results in the not-very-helpful error message:

expected function body after function declarator

We should improve the error message for this situation in clang. This is an easy error to make. In addition, it would be helpful to clearly document in the Checked C language extension that for function return values, the bounds declaration is part of the function declarator.

Note that this odd case is really a result of the complex way that return types for functions are declared in C. This case doesn't happen when using the new checked types. Instead one has

ptr<int[10]> r31(int arg[10][10]) {
  return arg;
}

Bounds expressions need to processed during clang's semantic checking/processing phase in a scope with all the parameters available. I am about to submit a pull request where they are being processed in a scope that contains only the parameters seen so far.

This is a little complicated to implement in clang's semantic checking/processing phase. You have to delay parsing of the bounds expressions because parsing and semantic processing are intermixed.

Printing a type mismatch when only bounds information is mismatched for a function type will be confusing to users. We need to detect this situation and print a more useful error message.

A conflict could arise in a situation where a functions bounds-safe interface specifies _Ptr<T> for something in an interface, but our analysis determines that it can't be a _Ptr. In that situation, we have some Checked C tools at our disposal to deal with the problem (like casts) but the constraint library can't deal with this situation at all.

The constraint library should be modified so that:

• Constraints that "hold a value down" are possible (i.e. q_i != ARR /\ q_i != WILD)
• Conflicting constraints are identified and reported as solve failures

Once that's done, the client of the constraint library can start to implement solutions to conflicts discovered around external specifications.

The compiler checks that return bounds declarations are only used for return types that can have bounds expression. For example, a function that returns a float cannot have a return bounds declaration. Some of the error messages incorrectly suggest an array type as one of the possible valid types. Functions cannot return array types, so this is confusing and should be fixed.

The Checked C specification has relative bounds expressions. We need to extend the IR to represent relative bounds expressions, add parsing support for that, and add typechecking for that.

Parse in-line bounds declarations for struct members.

Bounds expressions and where clauses can only use non-modifying expressions. The checking for this needs to be implemented.

An expression with a count bounds expressions must have a pointer type. The type cannot be a pointer to void.

We decided to stick with the existing rule in the specification that all dimensions of a multi-dimensional array must all be checked or unchecked. There is no need for the ability to declare unchecked arrays using the 'unchecked' keyword, so we should remove this feature.

C allows type modifiers or the keyword static to appear within the brackets for an array declarator for a parameter. For example, int a[static 10] means that a should only be passed arguments that have at least 10 elements. int a[const 10] means that a should be treated as having const pointer type in the body of the function.

The code for parsing type names for bounds-safe interface types for parameters did not allow these syntactic forms. This could cause problems for adding bounds-safe interface type annotations to code that uses them. The interface type and the declared type must be identical when checked-ness is ignored for pointers and arrays. We should add this support.

The logic in NewTyp::mkTypForConstrainedType is ugly and probably wrong in some cases. It should be replaced with either a ginormous switch statement (which is more intuitive from an ML-persons point of view, but not LLVM idiomatic) or a RecursiveASTVisitor (which is ugly from an ML-persons point of view because functionality is smeared across a bunch of tiny functions, but is LLVM idiomatic).

The clang implementation of bounds in function types only supports references to global variables or parameters declared as part of the function declarator for a function type. We should add checks that enforce these restrictions. Otherwise typechecking may behave in unexpected ways.

In FunctionVariableConstraint::mkString we take the first constraint in a set for the return and parameters and use them. Right now this should be okay because they should all be constrained to be equal, so whatever one is resolved to should be the same as the others. However, maybe in the future that won't be true, so we should instead be more generic and take the LUB of all the ConstraintVariables in the set.

If a variable has unchecked pointer type and aptr interop annotations, this allows implicit conversions from checked pointer types to the unchecked pointer type. This issue is to implement the additional implicit conversions

We need to test printing, AST serialization, AST transformation, and AST serialization with the new Checked C features. This work item is to understand the tests that exist for these features and how to extend them to Checked C features.

There needs to be a representation of bounds information in function types. Currently the bounds information is not being included in function types. This is problematic because in clang, typedefs are represent as names that map to type object. Uses of typedef'ed names refer to those function objects. It is also problematic for typechecking pointers to function types.

One approach is to use DeBruijn indices: number all the arguments and then change bounds expressions used in types to refer to those arguments. We would need a way to represent uses of those arguments in bounds expressions. For now, we could require that two bounds expressions be exactly identical after this transformation. Later on, we could canonicalize bounds expressions and require that they have the same canonical representation. Even later on, we might check to see if one bounds expression implies another.

This work item is to check bounds declarations to pointers to constant-sized data, where the bounds have the form bounds(_x_ + _const1_, _y_ + const2).   We will check bounds declarations for a subset of expressions that are useful for creating ptr-typed values.  These include:

• address-of operators
• uses of unchecked arrays with known dimensions
• uses of unchecked arrays with known dimensions that are not parameters
• function calls.  For function calls, we will need to substitute constant argument  expressions for parameter variables occurring in the return count.  We will then need to determine whether the resulting expression is a constant-expression.
• casts

It also includes checking bounds at

• Simple assignments
• Function calls

Type check bounds declarations and bounds expressions that use bounds, following the rules outlined in the Checked C design. These can be used in parameter declarations, variables declarations, and for function return, following the rules outline.

It would be good to have one kind field on bounds expressions instead of specialized kinds per type of bounds expressions. This would make it easier to write code that traverses bounds expressions. Currently, we have to test the type of a bounds expression and then look at the kind field.

The rewriter should have some documentation, both externally facing and developer documentation. They should be added to the folder docs\checked.

We need to allow a bounds declaration to be omitted on a parameter with unchecked pointer type in one function type and to appear on corresponding parameter in the other type. A similar rule needs to apply to function returns.

We should only allow the Checked C extension flag to be used for C in clang. We should issue an error message for other languages. We're not currently doing the implementation work to enable all the language features for other C family languages supported by clang (such as C++). We're also not testing the other C family languages.

The Checked C clang implementation is not typechecking returnb ounds expressions for function pointer types. The following two methods compile without errors:

void fn121(int (*fnptr)(void) : count(5));
void fn122(array_ptr<void> (*fnptr)(void) : count(5));

The first case declares a return bounds expression of count(5) for an integer return value, which is not legal. The second case declares a return bounds expression of count(5) for an array_ptr return value, which is also illegal.

Let's say you have a typedef that looks like this:

typedef struct _A { 
  int a;
  int b;
} A, *PA;

There are two variable declarations somewhere in the program:

PA p1 = foo();

and

PA p2 = bar(); 

In one scenario, both foo and bar are unconstrained and can be PTR. The re-writer could make one edit, in the typedef, to change the definition of PA to be ptr<struct _A> PA. Then this will just work.

However, let's say that the return value of foo is PTR but bar is constrained to not PTR. So one of these will be re-written to ptr and another won't. Can we do better? One option is to create a new typedef, but there are questions to be answered. What is this typedef called? How do we disambiguate it from the old one? And so on.

Come up with a spectrum of answers to this question and implement them.

We want to leave those alone. Right now, we do string compares, which is both non-idiomatic and brittle.

Section 3.2 describes restrictions on variables at external scope that have bounds declarations. These restrictions need to be implemented.

At function calls, we need to enforce rules that checked types are not passed to functions with no prototypes.

Bounds-safe interface type annotations currently have the syntactic form type(type name). The usage of the name type is potentially confusing. It could be literally be interpreted that this is specifying a new type for the declared variable. We are going to use the name itype instead to reduce the potential for confusion. This is an abbreviation for interface type.

For interoperation, we will redeclare existing library functions with additional bounds information. We assume that modifying library source code is not possible when modifying programs that use libraries. We'll have to add bounds information separately. C allows functions and extern variable to be redeclared, so long as the redeclared versions are compatible with the existing version.

We need to extend the code for checking redeclaration to take bounds into account. For parameters or variables of array_ptr type, bounds will have to match. For now, we will use syntactic equality. If they have unchecked pointer type, if they both of have bounds, they must match. Otherwise, the bounds will be regard as being part of a more "complete" declaration of the parameter or variable.

This should be fairly simple: ensure that the expression has an integral type.

Parse inline bounds declarations so that we can attach bounds information to function parameters.

C has a well-established design pattern for introducing new keyword: prefix them with _. This reduces the chance of inadvertent naming conflicts from new keywords. This was used to introduce the Boolean type, for example. The keyword in C is _Bool. The unprefixed keywords can be used by including a header file that #defines the unprefixed keyword to the underscore based keyword. For example, the standard header file stdbool.h does this for Boolean.

We have observed that real-word code such as the Windows header files uses ptr as variable and field names, so we will switch to the C pattern.

We have a global variable named Tok and a parameter needed tok. The code is mistakenly using Tok in one place instead of tok. The fix is to rename the parameter variable so that the names are distinct when case is ignored.