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

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.

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.

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

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

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

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.

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.

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.

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.

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.