Maybe, but the thing about unsafe is, it isn't like fairy dust so sprinkling it on stuff doesn't help. This is a common misconception from people who haven't worked with unsafe (even if they've written some Rust)

ten_things[11] = blah; // is a buffer overflow so it either won't compile or it panics

However

unsafe { ten_things[11] = blah; } // is still a buffer overflow, same effect but also Rust warns that unsafe is useless here and should be removed

Now of course we can write a potential buffer overflow in unsafe Rust, but now we're not just sprinkling unsafe on stuff and hoping, we've got a plan, perhaps a stupid plan but it's a plan so that's an improvement.

I agree with you but just for completeness the rust equivalent is unsafe { *ten_things.get_unchecked_mut(11) = blah }

Which goes to show that usually the unsafe methods are more verbose and annoying to deal with. Devs won't reach for them just out of laziness.

I'm sure you're much more knowledgeable than me about Rust at least.

Still based on my experience reading early Redox code it was chock full of unsafe blocks, and I suspect they didn't do that out of malice but to expedite development.

So the risk might still be there.

Redox: “ A quick grep gives us some stats: the kernel has about 300 invocations of unsafe in about 16,000 lines of code overall.”

https://doc.redox-os.org/book/ch01-07-why-rust.html

This is probably not an up to date number but it gives you some idea of a random snapshot in time at least.

Well if I knew less than the last guy I'm defo beat here :)

Would be interesting to see what those figures were like 5 years ago (i.e. a year or so after its initial release). It seems like the concern here is that embedded Dev for cars isn't getting getting to maturity.

I don't see why it would. Extra locks help paper over bugs you can't figure out. Unsafe would never do that.