Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I cannot consistently write safe C/C++ code

robert.ocallahan.org

Post reply on HN
Print view View original

71–80 of 123 posts

Re: I cannot consistently write safe C/C++ code

#71

Post by kbenson »

Loony2 wrote: post #44
kbenson wrote: post #26

Earlier quoted context omitted.

This is a rebuttal against "use a safe language and all your security problems go away entirely" but that is not generally the argument being advanced. The argument that is generally advanced is "use a safe language and some of your security problems go away entirely". Put another way, people are arguing for airbags to become much more common, and your rebuttal is "I've gotten into some accidents, and I've gotten hur…

I agree, but I still believe that one issue here is the lack of understanding of what the process around software development should be. We would get rid of some issues if we used a safer language, but the real issue is that we don't find the issues, the attacker does instead. So people are finding the issues, but why are not the people writing the software finding them? I believe that you should have a development t…

> We would get rid of some issues if we used a safer language, but the real issue is that we don't find the issues, the attacker does instead. So people are finding the issues, but why are not the people writing the software finding them?

Attackers aren't finding all the issues. They are finding issues in the small subset of software they actually bother to examine. That programmers aren't finding the issues I think illustrates both the effort it takes to always be correct as well as the different skills that are leveraged differently. It doesn't take a good C systems or application programmer to find a lot of the common C unsafety errors in question. It takes someone that knows the C memory model and has the knowledge of how to leverage that commonly. In some cases it takes someone applying new fuzzing techniques to expose certain edge cases more consistently that prior fuzzers did.

> That means you run the same tests, no matter the language, so in the end it doesn't matter what language you write it in.

The important point you are assuming is that the language (or current implementation of it) won't change out from under you in a way that makes that assumption invalid. See my other comment in this discussion regarding DJB, and the HN comment I link to for a good discussion about why that's so.

> And you chose a language that fits the problem, you don't make the language fit the problem.

In what case when you have two languages roughly similar in capability but one allows errors the other doesn't is the one that allows the errors the better fit?

> So I think your analogy of an airbag is wrong in some sense. The issue isn't weather we have an airbag or not, the issue is that we don't test if we have an airbag and then go "Whoops, the airbag didn't deploy in the crash and somebody died".

Then you're misunderstanding my analogy. The car isn't the program written, the car is the compiler. The route driven is the program. You may make an error on the drive, but let's let the car save us in those cases where it's obvious it can and should. Sure, making sure your coworkers check you've secured the pillows to the steering wheel before every trip works, but it should be obvious why that's sub-optimal in multiple dimensions.

> I work at a place where we have written code for 15 years, not only C code, or more without any remote exploitable holes.

I congratulate you on your diligence (sincerely, it is an accomplishment to get to the level where you feel you can say this), but that's a strong assertion in at least one possible interpretation. Perhaps you meant no remotely exploitable holes found? The interesting question that immediately arises from that clarification is whether anyone has seriously looked? Companies that care about this hire pen testers. I hope yours does as well.

Re: I cannot consistently write safe C/C++ code

#72

Post by masklinn »

adambard wrote: post #24
simias wrote: post #5

I think this whole "competent coders don't make mistakes" is a testament to the immaturity of the software development world. Real men write in assembly, maybe C if they're a bit tired. It would be like a construction worker saying "only noobs need a hard hat" or a surgeon refusing to wash their hands because they're careful never to touch anything contaminated. Or maybe simply refusing to wear your seatbelt because…

> or a surgeon refusing to wash their hands because they're careful never to touch anything contaminated. Fun fact, although perhaps this is specifically what you had in mind: This was pretty much the case until Ignaz Semmelweis [1] noticed that washing your hands caused patients to die less frequently. His suggestion was not well-received by the establishment: > "Some doctors, for instance, were offended at the sugg…

Surgical checklists have met (and are still meeting in some places) the exact same opposition, which pilot checklist also met when first being implemented.

Re: I cannot consistently write safe C/C++ code

#73

Post by adrianN »

millstone wrote: post #68
SeanDav wrote: post #29

Earlier quoted context omitted.

I doubt writing safe C/C++ code is as straightforward as the Parent post claims, otherwise people at Microsoft, Google and Mozilla must clearly be doing something wrong. They have the budget, the skills and the motivation to always produce safe code, yet their products all contain serious bugs, which would not occur if all their C/C++ code was "safe".

We know how to write C/C++ code appropriate for safety-critical components, it's just very expensive and slow to develop. Any company who set out to write a social networking system at an ASIL D level (say) would be rapidly out-competed. ISO 26262 recognizes this, which is why different components in your car are developed to different integrity levels. No lives are lost if Firefox misrenders a JPEG, so it has a low…

I've read those safety standards and I disagree. They don't prescribe much that isn't standard practice. The only thing they require that isn't commonly done is very extensive testing or formal verification. They high expensive mostly comes from proving compliance to external auditors. You could have 90% of the results with 10% of the work by just testing your software very thoroughly but not producing all the documentation required to prove compliance to the standard. SQLite for example is at least as rigorously developed as SIL 4 software.

Re: I cannot consistently write safe C/C++ code

#74

Post by daemin »

alfiedotwtf wrote: post #66
ccommsxx wrote: post #57

Earlier quoted context omitted.

Well, I agree with you on practically everything you said. Just for the record, I never intended to imply that somebody should not criticize their tools until they fully mastered them and I certainly don't claim to have done so. I just (tried to) say that I don't like it when others recite opinions from some blog post without even a basic understanding of the issues at hand as I find it leads to a very superficial di…

Let's say you're a fresh grad and looking at options for you future dev career: Option 1. Spend the next 5 years learning the ins and outs of C++, where it can bite you, where it can go wrong, all the intricate edge cases, etc... and you'll come out a better C++ programmer. Hopefully after 5 years of hard concentration, you may be able to write safe code (I still haven't met a C++ programmer that hasn't been burned b…

That assumes there will be no errors in the Rust compiler or runtime environment to deal with. If there are then those would definitely be above their pay grade.

Re: I cannot consistently write safe C/C++ code

#75

Post by fnl »

simias wrote: post #51
ccommsxx wrote: post #27

The worst thing about these kinds of articles is the troves of junior programmers that never touched systems programming with a stick before but will read this on hackernews today and sit in the office tomorrow lecturing seasoned coders how they´re dumb for not having seen the light and using an unsafe language. This is how stupid cargo cult gets made, guys. It's easy to repeat some talking points that you found on t…

Beginners will feel overconfident and some will even try to teach more experienced coders how to do things "right" regardless of these types of articles. We've all been there and we probably still are in some fashion. I don't see how that diminishes the value of TFA though. Any kind of guidelines can be "abused" by taking it to the extreme without actually taking the time to consider if it actually makes sense. Also…

As already posted in another thread for this GP, I completely disagree with the overall sentiment of this whole discussion that is throwing (modern) C++ (i.e., C++11 ff.) into the same bucket with (any version of) C.

What I can agree to, however, is that C should be your first choice if (a) you have to, or (b) because you like it and probably (c) because you are several times more likely to find a job if you know C as opposed to Rust or Go (unless living in very specific areas of this world - maybe...?). And then go learn Rust/Go/..., anyways :-).

Re: I cannot consistently write safe C/C++ code

#76

Post by alfiedotwtf »

daemin wrote: post #74
alfiedotwtf wrote: post #66

Earlier quoted context omitted.

Let's say you're a fresh grad and looking at options for you future dev career: Option 1. Spend the next 5 years learning the ins and outs of C++, where it can bite you, where it can go wrong, all the intricate edge cases, etc... and you'll come out a better C++ programmer. Hopefully after 5 years of hard concentration, you may be able to write safe code (I still haven't met a C++ programmer that hasn't been burned b…

That assumes there will be no errors in the Rust compiler or runtime environment to deal with. If there are then those would definitely be above their pay grade.

I'd take a bug within LLVM over my own any day

Re: I cannot consistently write safe C/C++ code

#77

Post by alfiedotwtf »

ccommsxx wrote: post #69
alfiedotwtf wrote: post #66

Earlier quoted context omitted.

Let's say you're a fresh grad and looking at options for you future dev career: Option 1. Spend the next 5 years learning the ins and outs of C++, where it can bite you, where it can go wrong, all the intricate edge cases, etc... and you'll come out a better C++ programmer. Hopefully after 5 years of hard concentration, you may be able to write safe code (I still haven't met a C++ programmer that hasn't been burned b…

>> Spend the next 5 years learning the ins and outs of C++, [..,] Spend a single month learning Rust. Play with it for another month or even two just to be sure. Hopefully after the 3rd month, they'll be 100% certain that their code won't break [...] Rust gives me the confidence to "compile once, run safe everywhere". See, this is exactly the fallacy that I am criticizing. I think the belief that "C++ is too hard to…

Another scenario:

Option 1. Spends 5 years learning the ins and outs of systems programming, whilst using C++. Still writes unsafe code.

Option 2. Spends 5 years learning the ins and outs of systems programming, whilst using Rust. Zero unsafe code has ever been written.

Re: I cannot consistently write safe C/C++ code

#78

Post by MaulingMonkey »

stinos wrote: post #23
irundebian wrote: post #20

Nice post. There are still to many C/C++ wannabes who think C is an awesome language and their are awesome hardcore programmers. If they are challenged to code something, it's highly probable that flaws will come up.

There are still to many C/C++ wannabes There are still too many people using the term C/C++ :] It never really was a thing, even in the beginning (I mean, just take e.g. destruction at scope exit: that alone makes it a very different language) and now even less with the new standards. Anyway: a language can be considered awesome by people, despite it's flaws. Always has been, never will change, as there will probably…

I'm actually going to defend the term.

For starters, the languages are in practice quite similar as used in many codebases (e.g. C++ codebases where they just don't use destruction at scope exit, have exceptions and RTTI disabled outright, and eschew modern features in favor of targeting older compilers, etc. - or C codebases where GNU extensions are used to get automatic cleanup at the end of scope!)

Further, headers are routinely set up to be safe C and C++, with a few #ifdef __cplusplus extern "C"s to help manage name mangling. And I'm struggling to think of a significant codebase which I've actually shipped that was pure C++, rather than C++ with at minimum a few customizations to some third party C library, embedded as part of the same build (to say absolutely nothing of system libs.)

I suppose you could argue it should in some cases be C/C++/Objective C/Objective C++/(C++/CX)/(C++/CLI)/...

Re: I cannot consistently write safe C/C++ code

#79

Post by millstone »

skrebbel wrote: post #42
millstone wrote: post #25

> I cannot consistently write safe C/C++ code. I'm not ashamed of that; I don't know anyone else who can. With respect, two mistaken beliefs: 1: Only a few programmers can write safe code. 2: One will naturally encounter such programmers in the course of a prestigious career working for a high-profile web browser company. But mediocre programmers consistently write safe C/C++ code, every day. They do it in the contex…

That's a different kind of safe than the OP means. You mean "does not crash, produces the right results", he means "can'te be hacked". A non-networked engine control unit is super hard to hack by simple virtue of being unreachable from the internet. I bet if you run a fuzzer against your perfectly safe aviation code you'd find lots and lots of security issues. But those issues aren't important.

I don't follow your point. Software has to be prepared to deal with abnormal inputs, whether those are from a malfunctioning sensor, or an attacker on the same WiFi hotspot.

Safety is a property of a system and the context in which it's used. Safety is not a property of its individual components, including its code. If your CPU's GPIOs were directly accessible through the Internet, your computer would be hacked too; does that mean your system is not safe?

Re: I cannot consistently write safe C/C++ code

#80

Post by ccommsxx »

alfiedotwtf wrote: post #77
ccommsxx wrote: post #69

Earlier quoted context omitted.

>> Spend the next 5 years learning the ins and outs of C++, [..,] Spend a single month learning Rust. Play with it for another month or even two just to be sure. Hopefully after the 3rd month, they'll be 100% certain that their code won't break [...] Rust gives me the confidence to "compile once, run safe everywhere". See, this is exactly the fallacy that I am criticizing. I think the belief that "C++ is too hard to…

Another scenario: Option 1. Spends 5 years learning the ins and outs of systems programming, whilst using C++. Still writes unsafe code. Option 2. Spends 5 years learning the ins and outs of systems programming, whilst using Rust. Zero unsafe code has ever been written.

Again, the assertion that all code written in rust is automatically "safe" (let alone correct) is false unless you say what precisely you mean with "safe" in very specific terms. While there are some ways in which rust is "safe" while c-family languages are not, these cases are _subtle_ and you _will_ have to understand modern C++ first to see what they are.

But yes, rust could turn out to become a new widely accepted standard for systems programming some day and depending on whether you believe that or not, it might make sense to "invest" your time into it.

Post reply on HN