clang -fbounds-safety ...

https://clang.llvm.org/docs/BoundsSafety.html

On macOS you can try it with:

    clang -Xclang -fbounds-safety program.c

[1] https://github.com/swiftlang/llvm-project

Possible problems within a function should be discoverable.

This particular bug would be hard to discover for a typical linter unless they knew/remembered that there are two execution paths for cleanup of a given element.

Also nice the onion reference by op.

see https://scan.coverity.com/projects/linux for the linux-specific scan results - you need to create an account to view the reported defects.

This past couple of weeks isn't a good look for them with the releases of defects found in Linux and Firefox.

There are other free ones, I don't know if they're run as a matter of course.

Rust is bounds checked by default. C is not. Defaults matter because, without a convincing reason, most people program in the default way.

Also unsafe rust doesn't remove bounds checks. arr[idx] is bounds checked in every context.

You can opt out of array bounds checking by writing unsafe { arr.get_unchecked(idx) } . But thats incredibly rare in practice.

[1] https://cs.stanford.edu/~aozdemir/blog/unsafe-rust-syntax/

It’s always a way lower number than folks assume. Even in spaces that have higher than average usage.

The entirety of safe Rust is built upon unsafe Rust that's abstracted like this. The fact that you sometimes need unsafe isn't a mark against Rust, but literally the entire premise of the language and the exact problem it's designed to solve.

This is something a lot of people misunderstand about unsafe rust. The safe / unsafe distinction isn't at the crate level. You don't say "this entire module opts out of safety checks". Unsafe is a granular thing. The unsafe keyword doesn't turn off the borrow checker. It just lets you dereference pointers (and do a few other tricks).

Systems code written in rust often has a few unsafe functions which interact with the actual hardware. But all the high level logic - which is usually most of the code by volume - can be written using safe, higher level abstractions.

"Can all of io_uring be written in safe rust?" - probably not, no. But could you write the vast majority of io_uring in safe rust? Almost certainly. This bug is a great example. In this case, the problematic function was this one:

    static void io_zcrx_return_niov_freelist(struct net_iov *niov)
    {
        struct io_zcrx_area *area = io_zcrx_iov_to_area(niov);

        spin_lock_bh(&area->freelist_lock);
        area->freelist[area->free_count++] = net_iov_idx(niov);
        spin_unlock_bh(&area->freelist_lock);
    }

Really? Why? I've not used Rust outside of some fairly small efforts, but I've never found a reason to reach for unsafe. So why is "nearly everyone" else using it?

So the vast majority of Rust projects involve writing at least one unsafe block? Is that really your claim?

How do you know the unsafe operation is safe? What are the preconditions the code block has? Write it down, review it, test it.

I like type checking and other compile time checks, but sometimes they feel very ceremonial. And all of them are inference based, so they still relies on the axiom being right and that the chain of rules is not broken somewhere. And in the end they are annotations, not the runtime algorithm.

Yes, which is precisely why I write in Rust, because the compiler errs less than I do.

On the other hand, when you're relying on your ability to "actually write quite good C code"...you'd better hope that you have not made an error there. In practice, some of the most widely used C libraries in the world still seem to have bugs like this, so I don't really understand why you'd think that's a winning strategy.

[1]: https://hubris.oxide.computer/