Bounds checking slices makes code around 1% slower. It's worth it, but not free.

I mean, that was the fix in this situation too, anyway. "free" depends on what you're comparing it to.

Are you sure? CloudFlare's problem seems to have been running off the end of a logical buffer embedded in a linked list of "physical" buffers.

(Sorry, have to run - will try to take a better look later tonight.)

In Rust you'd usually use a slice for this anyway, which has bounds checks. Yes, you could use indices instead, but that's not very Rusty (and more annoying to use!), whereas using pointer arithmetic is par for C.

Edit: Yes, you could ultimately get it wrong in Rust, too, I just think it's much less likely.

So you're thinking of an iterator of slices of char (arrays), right?

It still somewhat tricky to get right to me; the writer wants to have access to the underlying physical buffers, so you need a conversion step from list-of-physical-buffers without allocating, etc. But you're probably not wrong that a Rust programmer is more likely to get this right; thanks!

(And it's all likelihoods anyway; there's plenty of C code that doesn't get this wrong, and e.g. the VALGRIND_MAKE_MEM_UNDEFINED() I suggested above does reliably - albeit dynamically - find this problem in C.)

(Added a reference from my top comment to your reply.)

You don't need to allocate, Rust slices are safe zero-copy views into an existing buffer.

Yes, you can run under valgrind, but dynamic checks ... :)

You need to have testcases that hits those code paths, and it's really hard to make "unexpected" testcases that test code paths like these. That's why fuzzing is awesome!