Live data from Hacker News

I cannot consistently write safe C/C++ code

robert.ocallahan.org

51–60 of 123 posts

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

#51

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 while I do have significantly more than 10 years of experience in C I think it's silly to say that you can't criticize the language if you can't recite the K&R by heart. You don't need to know all the intricacies of C's aliasing rules to peruse the long list of CVEs caused by faulty memory handling.

The world of computing changed drastically over the past decades, for a given application maybe C or C++ was a great choice in the 90's, doesn't mean there's no better alternative now.

People telling everybody to ditch C like it never existed and rewrite everything in Rust or Go are silly and are probably the junior coders you're talking about who lack real world experience. Doesn't mean that the opposite reaction of "if it ain't completely broke don't fix it" is any more clever.

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

#52
post #21

I've worked in "IT security" as a C programmer for about 10 years. I both agree and disagree with this article. A competent C/C++ programmer will have a lot less of problems like buffer overflows and crap like that, I don't think a buffer overflow has been found in any code I've written during my 10 years as a C programmer. I have still written code that has security issues though, most of them stem from poorly desig…

I bet there's at least one bug in code you wrote 10 years ago relating to buffer overflows caused by integer overflow. You may have been checking every input against the size of your buffer, yet still have had a buffer overflow. Every integer addition when dealing with buffers is suspect.

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

#53

It makes me smile when someone starts off a complaint with something similar to "I've been programing in C++ for x decades. I have y qualifications that should impress you. I worked at z company which should impress you further. Yet, despite this, I cannot write safe C++ code". The author's post, in particular, is excellent as it follows this token introduction with "I don't know anyone else who can write safe C++ co…

> Get over yourself

The guy is simply describing his personal experience. Why don't you describe your own personal experience instead of attacking him?

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

#54

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

As long as no one does something silly a decade from now when it comes to the networking on the plane/ship/factory.

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

#55
I wonder how can anyone even use computers these days, since C and C++ are so unsafe. My OS is written in C and C++, also my browser and my word processor, my shell and most of the applications that I daily use. The firmware in my phone, my set-up box and my car is also written in those two languages. Also all the major web servers are written in those to languages. Maybe Rust programmers are an exception, but I personally spend 99,99% of troubleshooting time (in any language) on fixing logical bugs that I make. It's hard to get excited about a language like Rust, when it seems that it's community is only interested in spreading FUD.

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

#56

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

In automotive, code is very rarely written it is mostly generated from simulink models. But yes software for aviation automotive, nuclear and medicine equipment are running safe C code. It is mostly generated from a model not necessarily simulink. The generated code usually have rules for the code so no global parameters, no pointers etc can be used.

That's a great point. Often you need to run your system in simulation via a model. Generating the code directly from the model is one way to prove that your system matches the simulation.

Of course the modeling tools speak mostly C. This illustrates how C's weaknesses are mitigated in practice, and how much work prospective C-replacements must do to be competitive.

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

#57
post #51

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…

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 discourse. I also didn't mean to imply that new projects should be done in C/C++ for the sake of historical reasons or something similar.

In fact, I actually recently started working on a new project, written in rust (!) in an industrial setting. Part of the reason for my original comment is that I found there was _a lot_ of cult in content related to rust, in their marketing material and on rust-related posts on HN. While I really like some parts of the language, this aspect of the rust community is really turning me off at the moment and I hope it will get better over time.

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

#58
post #35

Earlier quoted context omitted.

Fact 1, the article doesn't mention Rust a single time. Fact 2, mostly safe systems programming languages exist since ESPOL (1961), 10 years older than C, and with a great linage of attempts of safe systems programming outside AT&T walls, so plenty of alternatives are available So as someone with more than 10 years of C and C++ experience, among other programming languages, before focusing on Java and .NET, I find th…

I feel you're missing my point. The article doesn't mention rust but my comment was phrased in the context of the current rust craze on HN. As I said, I agree with you and the author that all of us do inevitably make mistakes. I also agree that the c-family of languages makes it somewhat more easy to shoot yourself in the foot in a bad way than others. I'm not saying innovation on safe languages is bad, or that using…

The main issue I have found out during all these years of advocating safe practices in C and C++, specially among C developers given that the C++ community does care about type safe programming, is that they land in deaf hears.

Currently, writing blog articles re-explained what is bad and should be avoid seem a waste of effort, given that even respectable researchers like DJB get ignored.

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

#59
post #14

> I cannot consistently write safe C/C++ code. I'm not sure how to interpret what this means. What do "consistent" and "safe" mean? Is safety about not corrupting program data? Even when dealing with Python arrays, I can end up corrupting my arrays one way or another (off by one, race conditions, etc.). Is "consistent" about going days without a bug? Because I can't do that in any language. If not, what do these mean…

Of course every programming language is not perfect, including its library and related implementations. In all of them is possible to introduce logical bugs. The problem with C and its derived languages is that not only one has the logical bugs common to all programming languages, there are the memory corruption and UB introduced bugs to worry about as well. While one can think as being super competent, make use of a…

The good thing about C is there is an amazing tool support that can make it as safe as any other language. The bad thing about C is that most developers don’t know about (or don’t use) all the tools.

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

#60
post #48
post #32

Earlier quoted context omitted.

> But mediocre programmers consistently write safe C/C++ code, every day. I think perhaps you and the author have different interpretations of "consistently". You might also differ on whether "safe code" is safe just because it hasn't failed (or been reported!) yet under current inputs. > They do it as part of a much larger safety process, that is designed to be robust against faults at all levels So, since we seem t…

OK. I also made mistakes and I understand you. However you should perhaps move the disclaimer to the top of your post, so people have a chance to abort reading your post.

I could, but in this case I think it's more powerful as a reminder to be careful about interpretation for those that are in agreement with the original statement and then come upon the revision. That it might initially reinforce someone's similar mistake to then confront them with the fallibility of human nature appeals to me.
Post reply on HN