XNU kernel heap overflow due to bad bounds checking in MPTCP

That argument isn't nearly as persuasive in kernel space as it is in user space. Certainly not when performance and bleeding-edge techniques (orthogonal to or even in opposition to the normal idiomatic patterns newer languages emphasize and optimize) are as emphasized as they are in Linux. How many bespoke hash, tree, and queue data structures exist in the Linux kernel, each with purposeful but complex data and execution flow dependencies unique to their context? Every time someone tries to unify two, one more pops up. Point being, the Linux development model--partly because of the nature of the work, partly because of the particular culture--absolutely defies attempts at drawing lines between safe and unsafe so the latter can be isolated. Code that doesn't heavily rely on unsafe techniques, directly or indirectly, wouldn't normally be in the kernel, anyhow.

And particularly in a kernel environment even @safe code can do things that violate or exacerbate assumptions elsewhere in the code (e.g. complex RCU protocols), thus Linus' preference to avoid languages with a lot of implicit machinery or non-obvious execution flow. So it's not like @safe code can simply be removed from the equation.

You can pass real references to arrays using C99's variably modified types:

  int foo(int len, int (*arr)[len])
  {
      printf("number of elements in *arr: %zu\n", sizeof *arr / sizeof (*arr)[0]);
  }
  
  int main()
  {
      int a[6];
      int b[10];

      foo(6, &a);
      foo(10, &b);

      return 0;
  }

If you do this, the compiler clearly has the information to do at least dynamic bounds checks in 'foo', which it may also be able to statically eliminate (eg if there is a loop from 0 to len - 1).

It might be nice if there was some syntactic sugar for this that made the 'len' parameter implicit and unnamed, and didn't need the explicit & / * on the array pointer.

> what's missing is actual array references

Yes, that's what I mean. I point this out and I think people often assume I'm talking about replacing c style arrays instead of what I really mean, adding a bounded array reference type.

And yes it's true that you wouldn't be able to pass it to string functions and API's that take standard array/pointers. But still would be really really nice to have that in the tool box. because a lot of times getting things correct with minimal hassle and 'brittalty' is more important then speed or code size.

But they key safety feature is bounds checking, not just preventing the decay to pointer.

The most important of these language facilities, IMO, is Rust's "fat pointers". In Rust, a "&[T]" is not a single word but two: the first word is a pointer to the first element like in C, but the second word is the number of elements. This keeps both together all the time; you don't normally have the pointer separated from the number of elements (although you can separate them if you really want to), which is what allows the compiler to insert the bounds checks.

(Another interesting use of fat pointers is in Rust's "trait objects", where the first word of a "&Trait" is a pointer to the object, and the second word is a pointer to the vtable. In C++, the pointer to the vtable is part of the object; in Rust, it's part of the reference.)

Rust has more than just bounds-checks.

Rust heavily encourages the use of iterators and functional-programming both of which prevent buffer overflows by making code that could overflow less idiomatic.