Zig 2024 roadmap

Rust is quite precise in what memory safety means. First and foremost it means that it is impossible to invoke undefined behavior, e.g. data races. It certainly does not mean that the owner of a portion of memory cannot write data to the memory.

> I work on a C software that use a custom memory manager. It works this way:
> Use mmap to allocate a large ( 1GB to 1TB) array of virtual memory.
> The custom memory allocator will give you a range of indices that you can use in this array.

The question is: Who owns the array? If it is owned by the allocator, then all reads and writes must go through the allocator. Only the function/struct that owns this array is allowed to access it. Of course you can give away mutable access to the array, but again, there can be only a single owner of the mutable reference.

> From the point of view of rust (and valgrind!), all the memory is owned by main(), there is no pointers, all accesses are checked to be within the bound of the allocation, all memory is initialized etc.

Why should the memory be owned by main()? It should be owned by your custom allocator (which is transitively owned by main()).

> But really, there is nothing that prevent the code to write outside the allocated range of indices as long as it is inside the array. So buffer overflow are still possible, even though the memory manager is safer than malloc.

It depends how you give access to the memory. If you really only give indices and have a functions in the allocator for reads and writes, then yes, you have a function that can write to arbitrary locations in the array. It is perfectly safe to do so and this will not invoke undefined behavior. The program might not do what you want, but this is not what memory safety means.

If you you give slices of the array, then each receiver of a slice can only write to that slice and you have bounds checking etc. This is the only way different parts of the program can modify parts of the array independent of each other. However, rust will make sure that they only write to the parts of the array, the custom allocator has reserved for them. Writing such an allocator certainly requires some unsafe code to split up the one array into several smaller pieces that have independent lifetimes. There is at least split_at_mut() as a safe abstraction, so you could build this type of allocator using only safe code, but you certainly will need a bit more fine grained control if you really write an allocator yourself.

Valgrind will only see individual allocations, but rusts ownership tracking can be much more fine grained than a single allocation from the system allocator. And clearly it will ensure that you cannot overwrite the stack and that there are no data races and much more.