C-rusted in a Nutshell

C-rusted is a pragmatic and cost effective solution to up the game of C programming to unprecedented integrity guarantees without giving up anything that the C ecosystem offers today. That is, keep using C, exactly as before, using the same compilers and the same tools, the same personnel . . . but incrementally adding to the program the information required to demonstrate correctness, using a system of annotations that is not based on mathematical logic and can be taught to programmers in a week of training.

1. What is C-rusted?

C-rusted is an innovative technology whereby:

1. C programs can be (partly) annotated so as to express:
   • ownership, exclusivity and shareability of language, system and user-defined resources;
   • dynamic properties of objects and the way they evolve during program execution.
2. The (partially) annotated C programs can be translated with unmodified versions of any compilation toolchain capable of processing ISO C code.
3. The annotated C program parts can be validated by static analysis: if the static analyzer flags no error, then the annotations are provably coherent among themselves and with respect to annotated C code, in which case said annotated parts are provably exempt from a large class of logic, security, and run-time errors.

2. Which kind of resource management errors can C-rusted prevent?

Missing allocation, missing initialization, missing deallocation (resource leak), use after deallocation, multiple deallocation, race conditions due to sharing.

3. Which kind of resources are amenable to this treatment?

Anything:

• Language-defined resources: memory blocks, stream-controlling objects, mutexes.
• System resources: file descriptors, sockets.
• User-defined resources: all sorts of transactions, anything that requires allocation, deallocation and disciplined exclusive and/or shareable use.

4. What are the “dynamic properties of objects”?

Consider this example:

The (static) type of fd is int for its entire lifetime. But the value of fd has properties that change throughout the function body: these are dynamic properties. Assuming a POSIX implementation, at line

line 2.

fd value is indeterminate;

line 3.

fd value is either the erroneous value -1 or an open file descriptor;

line 5.

fd value is the erroneous value -1;

line 8.

fd value is an open file descriptor;

line 11.

fd value is an ordinary integer and cannot be used as a file descriptor.

5. Which kind of errors can C-rusted prevent thanks to the tracking of dynamic properties?

In addition to resource management errors, missing detection of erroneous or anomalous conditions, use of possibly tainted input data, unwanted disclosure of sensitive information.

6. Is C-rusted a new programming language, like Rust and Zig?

No: it is standard ISO ‍C, just used in a peculiar way and in association with suitable static analysis techniques.

7. Does C-rusted require a C18 compiler?

No, C-rusted is compatible with any version of the ISO ‍C Standard and can be used with any C ‍toolchain.

8. Is C-rusted compatible with MISRA C?

C-rusted is 100% compatible with MISRA C: a C program that is MISRA compliant can be rusted without negatively impacting MISRA compliance. To the contrary, an annotated C-rusted program has strong guarantees of compliance with respect to guidelines, such as those concerning the disciplined use of resources, error handling and possibly tainted inputs, for which compliance is much harder to achieve and argument in other ways.

9. Does C-rusted comply with the prescriptions of functional safety standards?

Yes. Functional safety standards such as ISO ‍26262 prescribe the use of safe subsets of standardized programming languages used with qualifiable translation toolchains. Insofar a C-rusted program is a C program where the presence of annotation does not invalidate MISRA compliance, C-rusted fits the bill as C does and more, due to the strong guarantees provided by annotations. Contrast this with Rust and Zig: they are not standardized and, as a matter of fact, they frequently change in a way that does not follow a rigorous process. This is the main reason why qualifying a Rust or Zig compilation toolchain is impossible today.

10. Isn’t C-to-Rust transpilation the solution?

It isn’t. Transpiling well-written C code to unreadable and unmaintainable Rust code solves only a small fraction of the problems and creates many new problems.

11. Is C-rusted verbose or does it anyway subvert the way C programmers work?

No and no. Annotations can be embedded into typedefs so that, e.g., the declaration of singly-linked list node objects passes from the plain C version on the left to the C-rusted version on the right:

Here, the e_opt_hown annotation encodes the information that next may be NULL or point to a Node object in the heap of which it has ownership.

12. Can C-rusted be adopted incrementally?

Sure! C-rusted does not force you to annotate all code: new code that is critical can be created with annotations from the outset, and this will speed up development because the C-rusted checker will immediately warn you about any mistakes. Legacy code can be annotated later, if there is value in doing so, or even left unannoated forever: touching proven-in-use code with a honorable operational history makes no sense. Note that common libraries, such as the C ‍Standard Library and the POSIX Library, have been annotated once and for all.