Checked C

Microsoft: "Rather than changing the run-time representation of a pointer in order to support bounds checking, in Checked C the programmer associates abounds expression with each_Array_ptr<T>-typed variable and member to indicate where the bounds are stored. The compiler inserts a run-time check that ensures that deferencing an_Array_ptr<T>is safe (the compiler may optimize away the runtime check if it can prove it always passes). Bounds expressions consist of non-modifying C expressions and can involve variables, parameters, and struct field members. For bounds on members, the bounds can refer only to other members declared in the same structure."

Me: No array descriptors are generated by the compiler. The programmer tells the compiler the size of the array as an expression, and that expression is evaluated at the point in the program where the relevant declaration appears.

The Microsoft syntax is very Microsoft. It involves many leading underscores and long keywords. What I proposed involved adding C++ "&" references, and making lengths explicit in the places in C where you can write "[]". This is more concise. The basic idea is the same, though. Arrays have a length, which is defined by some expression on nearby variables, such as other fields of the same struct or other parameters in the same function call. C programs that work usually have a length around somewhere, but the compiler doesn't know where it is. Make that explicit, and you can check.

If you add ranges and references to C syntax, and provide length information, you can deal with one of C's three big questions - "How big is it?" (The other two big questions are "who owns it?" and "what locks it?")

This area is 10% technology and 90% politics, so you need sizable organizational support to make much happen.

[1] http://www.animats.com/papers/languages/safearraysforc43.pdf

• C is valued for being super portable and compatible with every platform, including legacy ones, but this applies to specifically C89 or C90, and nothing else. As soon as you embrace new features, it's not your universal C any more. You're going to need newer compilers, new tooling, and that's almost like starting with a new language.

• C users have mostly self-selected themselves to like C the way it is: a small, flexible, zero-overhead language that isn't C++. Addition of checked containers, generics, and restrictions on pointer arithmetic, etc. make checked C not feel like C any more.

• Checked C still needs refactoring of the code. For large established codebases this is still a lot of work, and still a risk of introducing new bugs. It's very tempting to settle on just running one more analyzer, sanitizer or fuzzer instead.

And in the end with all this effort, back-compat break, whole-codebase refactoring you're still left with the old C, with headers and include paths, sloppy macros, ancient stdlib, painful dependency management, etc.

If you're going to rewrite C incrementally to a more complex dialect, and require a newer non-standard compiler for it, you may as well run c2rust on it first.

https://www.digitalmars.com/articles/C-biggest-mistake.html

i.e. just change:

    void foo(char* a)

    void foo(char[] a)

[1]: https://youtu.be/uqan23518Yc?t=610

As per wiki, they state that they have automatic conversion tools, but I highly doubt that this will be used in production, even in Microsoft.

Example from their wiki (https://github.com/microsoft/checkedc/blob/master/samples/st...):

    // Delete all c from p (adapted from p. 47, K&R 2nd Edition)
    // p implicitly has count(0).
    checked void squeeze(nt_array_ptr<char> p, char c) {
    int i = 0, j = 0;
    // Create a temporary whose count of elements can
    // change.
    nt_array_ptr<char> s : count(i) = p;
    for ( ; s[i] != '\0'; i++) {
        // We need to widen the bounds of s so that we
        // can assign to s[j] when j == i.
        // (In the long run, this will be taken care of by the
        // flow-sensitive bounds widening).
        nt_array_ptr<char> tmp : count(i + 1) = s;
        if (tmp[i] != c)
        tmp[j++] = tmp[i];
    }
    // if i==j, this writes a 0 at the upper bound.  Writing a 0 at the upper bound
    // is allowed for pointers to null-terminated arrays.  It is not allowed for
    // regular arrays.
    s[j] = 0;
    }

For a simple example, if you have a struct that has a pointer to an array that is allocated previously and that also has a length and maybe an allocated amount (and you're careful with making sure they are correct), then you can pass a pointer to the struct to a function that verifies that the length is sufficient for what is to be done and then the function doesn't have to check the length every time it accesses something in the array if it can be assured that the allocated memory or the length didn't change. This could save a lot of generic behind-the-scenes code that verifies the length every time an array element is accessed. It's up to the developer to make sure all the pieces are in place and everything is prepared before calling this function. If that code is in a tight loop, it could make a big difference in performance.

It's a sharp knife, but sometimes you need a sharp knife. You just have to be more careful. Dulling the blade makes it more safe, but it doesn't let you make use of it's sharpness.

Is it often overused? Probably. Does it have a steep learning curve to be able to write code that doesn't exhibit certain classes of errors? Sure. Should other options be used where performance isn't as critical? Probably. But it has it's place.

There is also cyclone.

Finally, if you missed it there is a new probabilistic variant of asan: https://llvm.org/docs/GwpAsan.html (and also a hardware accelerates one but only for ARM)

    #include <stdio_checked.h>
    #include <stdchecked.h>

    #pragma CHECKED_SCOPE ON

    int main(int argc, nt_array_ptr<char> argv checked[] : count(argc)) {
      puts("hello, world");
      return 0;
    }

[1] https://github.com/immunant/c2rust/

https://twitter.com/nixcraft/status/1361428043126996994?s=19

I'm a very experienced C programmer and what I would like, much more then a new language version, are some basic OS functions where I can query the status of a pointer. Is it readable? Is it writable? Where does the memory allocation start and end? Is the memory in the heap or stack, or a memory mapped file?

All the information is available inside the OS, but I cant get at it. If it was available it would be possible to write all kinds of instrumentation. If it was possible (in debug mode) to get the layout of the stack, that would also be super useful. Buffer overruns are really mostly a problem when they are on the stack.

By warping malloc and free, you can easily find buffer over runs, memory leaks and double frees. They become a none issue. But with stack memory you have very little control. I avoid using the stack for operations where this might be an issue, just because its so much harder to debug.

I would love to be able to write APIs that have built in tests (in debug mode) where all pointers are checked, and if anything is broken the API can fail gracefully and give out precise errors.