Modernizing C arrays for greater memory safety: a case study in the Linux kernel (opens in new tab)

Also what you're proposing...would be an extension!

> We can turn a pointer into a bounds checked array by "slicing" it:

> int *p = (int*) malloc(10); > int a[..] = p[0 .. 10];

When `p` is a parameter in a function, the function cannot know that it can create a slice of up to 10 elements (I assume that the `p[0 .. 10]` creates an array indexed from 0 - 9).

What if the line was:

     int a[..] = p[0..12]

> A bounds checked array can be turned into a pointer:

> int *p = &a[3]; // point to 3rd element of a[..]

Assuming that a indexes from 0 to 9, what happens when we use p with an out of range index, for example:

     int *p = &a[8];
     blah = p[3];

int (p)[n] = malloc(sizeof p); (*p)[i] = 1; // run-time bounds check

https://godbolt.org/z/vb8dqx1od

But yes, having a type that included the bound makes sense. But I do not think using array syntax for pointers as in your proposal makes any sense.

Dennis Ritchie got it right: https://www.bell-labs.com/usr/dmr/www/vararray.pdf

Ritchie DM. Variable-size arrays in C. The Journal of C Language Translation 1990;2:81-86.

I'm no guru, but I know from experience you can do it in C++:

  {0}[calvin ~] cat test.cpp
  #include <iostream>
  #include <memory>
  
  struct foo {
    int len;
    int v[];
  };
  
  int main(void) {
    auto p = std::unique_ptr<foo>(reinterpret_cast<struct foo *>(
        malloc(sizeof(struct foo) + sizeof(int) * 2)));
  
    p->v[1] = 99;
    std::cerr << p->v[1] << std::endl;
  
    return 0;
  }
  {0}[calvin ~] g++ -Wall -Wextra -std=c++17 test.cpp -o test
  {0}[calvin ~] ./test 
  99
  {0}[calvin ~] clang++ -Wall -Wextra -std=c++17 test.cpp -o test
  {0}[calvin ~] ./test 
  99

MyStructA a; MyStructB b;

a = malloc((sizeof a) + (sizeof b)); b = (MyStructB *)&a[1];

You need to make sure that the second struct doesn't have stricter alignment requirements than the one preceding it, but using this technique you can stack any number of structures or arrays of structures in one allocation.

(I would generally not recommend this coding style unless you have very specific requirements of memory usage)

No, the only standard way is to allocate a buffer large enough, and placement new the header and the bulk payload separately. The manual handling of alignment makes this very cumbersome.

Flexible array members would be nice, but I don't like that it is yet an other overload on some array declaration syntax (other meanings of "T x[]": 1) declare an array of unknown size, 2) in a definition, deduce the size). For some reason C likes to overload the array declaration syntax with widely different meanings (looking at you, VLAs).

For the latency to be significant digits, there must be a lot of repeated calls which only read/write a very small number of elements in the array. Otherwise the accumulation of read/write operations performed when iterating over the data would dwarf the single pointer dereference.

So I'm curious now-- do OS kernels spend most of their time doing lots of calls that dive into such dynamically-allocated data just to extract a single datum or two?

I'd say it's also not more dangerous (or equally dangerous, depending on your camp) than a pointer from malloc().

I am not an expert on C nor assembly and would be curious if you could expand on this. The statement makes sense to me because my impression is that most of what happens in C code gets translated fairly straightforwardly to machine code, with the compiler taking care of bridging differences in the instruction sets of targeted architectures. I guess the reason this is simplistic is the inlining and loop unrolling done by an optimizing compiler. Is this what you mean?

Not saying C is a great standard, but that idea means that using C instead of assembly doesn't generate a big overhead, and it's still much easier to write C than assembly, especially when compiler support is very common.

I'm currently making a language that translates directly to C.

In other words the C standard could make bounds-checking of arrays possible with a good interop story if the standards committee believed it was worth doing. Compilers would have a flag to enable or disable the runtime checks based on safety/perf tradeoffs. Libraries would slowly add the relevant annotations. Eventually most code would have the option of having all array accesses bounds checked.

> ...due to yet more historical situations (e.g. struct sockaddr, which has a fixed-size trailing array that is not supposed to actually be treated as fixed-size), GCC and Clang actually treat all trailing arrays as flexible arrays.

But I don't know, that doesn't seem to match the result I am getting with clang 13.1.6. It does seem to respect the array size declared in the struct, not treat it as a flexible array. I get -Warray-bounds warnings if I try to access anything past o->variable[3]. Maybe I'm misunderstanding what they're saying or my example is screwed up.

Edit: Actually, I guess it does end up treating it like a flexible array -- it produces -Warray-bounds warnings when compiling, but the resulting binary works (and doesn't trigger asan). Not sure I entirely understand it though.