> - You can change your language, but then you've put the bugs in your compiler / interpreter / vm.

I'd rather put my bugs in one, more easily verifiable place. Verifying all code that's ever going to be compiled is close to impossible. Verifying the compiler / interpreter / VM is hard, but it's much easier.

At the end of the day our field is basically: "get rid of repetitive work". So arguing that it's better to have total manual control (and basically always re-implement things at the point of use) doesn't strike me as the best approach.

"I'd rather put my bugs in one, more easily verifiable place." We are in agreement, that is why I was saying people shouldn't use C unless they need it.

> You can change your language, but then you've put the bugs in your compiler / interpreter / vm.

Sure, but the number of bounds-checking bugs in, say, the Rust compiler/stdlib is multiple order of magnitudes lower than if all Rust applications had to roll their own bounds-checking code.

Yes, but I am in agreement with you. I was simply saying you shouldn't blame C for being what it is, not that you should use it.

>You can change your language, but then you've put the bugs in your compiler / interpreter / vm.

memory safety issues account for an overwhelming amount of security bugs¹ and are avoidable by moving to managed languages. Compilers and VMs are very, very good at elimianting this primary source of bugs in code.

The first answer to the C/C++ problem should be to, whenever possible, move to languages that do a large part of the work for you.

In particular in the linux world it seems like a lot of application code that could be written in memory safe languages is still written in plain C.

[1]https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

We are in agreement, by comment was not saying people should use C. It was saying that a layer of unsafety has to exist somewhere.

Compiler bugs are fixable once and for all. Sloppy C coding practices persist since 70s - that's one big bug and it's unfixable.

I'm not sure I quite follow you, because if I believe what I think you believe, then I wouldn't call it "the problem of natural numbers", but I agree that C has no fault in it.

Precisely that which makes C so performant is also that which leads it to be "unsafe". It is thus up to the programmer to ensure safety in C, his manual managing of that is the price to pay for the performance gained using the language.

I was simply saying that it's undecideable to do bounds checking at compile time, so it's better to use languages that do bounds checking at run time. But you shouldn't blame C for this.