4 ms·

"How can I avoid being burned by C’s numerous and severe shortcomings?" I think this is where we start bumping up against the limitations of the universe we li

by jonv 7y ago

"How can I avoid being burned by C’s numerous and severe shortcomings?" I think this is where we start bumping up against the limitations of the universe we live in, because the question becomes "where do we put the bugs?". The biggest flaw with C is the array bounds checking, especially if that array is on the stack, or other bugs related to "raw" pointers: - We could enforce things through hardware, but then you've put the bugs in the microcode. - You can change your language, but then you've put the bugs in your compiler / interpreter / vm. - You can try and formally verify the correctness of your code, but it's less feasible for large codebases. And what if there's a bug in your proof? (proofs are programs) I'm not suggesting people use C/C++, but I wouldn't blame C for the problem of natural numbers.

majewsky 7y ago
> 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.
- jonv 7y ago
  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.
klingonopera 7y ago
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.
- jonv 7y ago
  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.
GoblinSlayer 7y ago
Compiler bugs are fixable once and for all. Sloppy C coding practices persist since 70s - that's one big bug and it's unfixable.
oblio 7y ago
> - 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.
- jonv 7y ago
  "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.
Barrin92 7y ago
>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-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
- jonv 7y ago
  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.

by jonv 7y ago

majewsky 7y ago

> 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.

jonv 7y ago
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.

klingonopera 7y ago

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.

jonv 7y ago
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.

GoblinSlayer 7y ago

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

oblio 7y ago

> - 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.

jonv 7y ago
"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.

Barrin92 7y ago

>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-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

jonv 7y ago
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.