It's trickier than it looks because C has mutable aliases. So, in C our bounds check might itself be a data race! Make sure you cope

Depending on what you are doing, yes. But the statement I responded to "your only choice is crash" is certainly wrong.

Bounds checks have nothing to do with data races. GP is right, you can add bounds checks. Either using macros or (in C++) with templates and operator overloading.

Alas, in C or C++ you have mutable aliasing, so I'm afraid you do incur a potential data race because your bounds might alias. Be careful out there.

Also remember that in C++ you may get a reference in these cases and if you keep that reference rather than using it immediately now you also have a potential TOCTOU race because the reference was only valid when you did the bounds check.

True, but you do incur potential data races _everywhere_. There's no relation to bounds checking specifically.

Ah, maybe I should have made the example clearer

With mutable aliasing the length might change even though the data you care about did not, and so adding the check means incurring a race which did not previously exist and which certainly the naive C programmer cannot see...

We can definitely mitigate this in the type system for most real world scenarios, but you don't mitigate problems you don't know about, so knowing is what's important.

If you can correctly add all the required explicit bounds checks in C what do you need Fil-C for?

Same reason any turing complete language needs any constructs - to help the programmer and identify/block "unsafe" constructs.

Programming languages have always been more about what they don't let you do rather than what they do - and where that lies on the spectrum of blocking "Possibly Valid" constructs vs "Possibly Invalid".

For temporal memory safety.