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

91–100 of 123 posts

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

#91

Post by posterboy »

fulafel wrote: post #7
faragon wrote: post #3

Yet another subtle pro-Rust rant against C. Programming is hard, and writing safe code requires knowledge, not just in C, but in every single language. Even in formal-validable languages you can make mistakes: may be you'll not make errors by using sprintf, but can make others because of using a more complex language.

Good risk management is about cost vs payoff analysis. To address the risk of car accident, first you stop juggling chainsaws while driving, then you start to wear seatbelts, and then you start thinking about how the remaining inevitable driving mistakes can be mitigated through technology or practices.

Safe subsets of C exist already. Any safeguards active at compile time could in principle be achieved via static code analysis. Only, if that means making assumptions and transformation to a different type system, that's like putting an old engine in a new car.

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

#92

Post by hsjoberg »

millstone wrote: post #56
hsjoberg wrote: post #28

Earlier quoted context omitted.

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.

Yes and the code/models go through extensive testing. Everyone in the industry knows that a callback because of faulty software will cost an insane amount of money. This is changing a bit since more and more work is going towards over-the-air update.

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

#93

Post by falcolas »

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.

If you are writing systems code, you will be writing unsafe code; it's just how it works when you are working with the underlying kernel and hardware.

The best you can do is attempt to contain it within "unsafe" blocks, but as has been proven by others in the rust community already this will not save the rest of your "safe" code from crashing if you write a bug.

There have been memory safe languages for longer than c has existed; rust is just the latest.

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

#94

Post by simias »

clarry wrote: post #85
simias wrote: post #63

Earlier quoted context omitted.

It's true but I'd argue that they're not really "coding" in C or C++ in the way it's commonly accepted in those critical environments. It's more like a "fill the blanks" exercise where everything is split in tiny functions that are thoroughly specified and tested. Effectively 90% of the dev work is done higher level by the various specification and constraint tools. All that's left to the C coder is the most menial o…

> int test(void) { > int i[3] = {0}; > > return i[8]; > } clang will warn. gcc will warn with -Wall -O2. > int *test(void) { > int i; > > return &i; > } You are free to use -Werror. I encourage people to learn to use their tools first. Instead of whining about the language when it is their tools that do not do what you want by default.

Oh interesting, GCC warns for the first code snipped only occurs with optimizations turned on. Still only a warning though.

And I don't think -Werror is a good general purpose solution because it's too broad. Many warnings are just fine as warnings and for big projects that build on several operating systems using a lot of 3rd party libraries there's bound to be a few harmless warnings here and there. For instance the perfectly valid "if (a && b || c)" will warn with -Wall. I guess I'd want a "-Werror-on-serious-warning".

That's why sane defaults matter, if those warnings were errors to begin with they would be fixed upstream, if instead you decide unilaterally to turn on -Werror for your code then you're screwed if your third party headers weren't as stringent with their coding rules.

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

#95

Post by clarry »

simias wrote: post #94
clarry wrote: post #85

Earlier quoted context omitted.

> int test(void) { > int i[3] = {0}; > > return i[8]; > } clang will warn. gcc will warn with -Wall -O2. > int *test(void) { > int i; > > return &i; > } You are free to use -Werror. I encourage people to learn to use their tools first. Instead of whining about the language when it is their tools that do not do what you want by default.

Oh interesting, GCC warns for the first code snipped only occurs with optimizations turned on. Still only a warning though. And I don't think -Werror is a good general purpose solution because it's too broad. Many warnings are just fine as warnings and for big projects that build on several operating systems using a lot of 3rd party libraries there's bound to be a few harmless warnings here and there. For instance th…

> Oh interesting, GCC warns for the first code snipped only occurs with optimizations turned on.

Right. So GCC isn't really a static analyzer. But it does the analysis that is required to perform certain optimizations, and as a side effect you also get some new warnings with the optimizations enabled.

> And I don't think -Werror is a good general purpose solution because it's too broad.

It sure is too broad for all existing software to compile, but if we're talking about security-critical software, what is with this double standard of bashing C for the lack of stringent checks per the standard and at the same time requiring compatibility with third party software that isn't built to the same standard?

I think if you're doing something security critical, then you must want the same stringent checks from all the libraries you use. Which means you choose the good libraries, or make your own, or fix the existing ones. Yes, positive encouragement from sane defaults could push other projects into doing the right thing, but as long as they don't, you really don't have to use their bad code in your security critical product. Yet, it is entirely usable. OpenBSD for instance compiles the kernel and libcrypto among other things with -Werror. Other parts of the system may be built with less stringent checks.

It is, by the way, possible to only turn specific errors into warnings with -Werror=... Likewise, you can disable specific annoying warnings.

I agree that it would be nice if compilers provided sane set of warnings (and errors) out of the box without any extra tweaking. I think we're getting closer and closer thanks to clang pushing things in that direction. On the other hand, I don't suppose people will ever agree which warnings are the right ones. I'd say most people who want stringent checks will enable -Wall and -Werror, and they will add the parentheses in the expression you mentioned, even if it is completely legit without them.

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

#96

Post by phaylon »

ccommsxx wrote: post #83
catdog wrote: post #81

Earlier quoted context omitted.

> Do c/c++ for 10 years, like the author, and then you're qualified to comment about the topic. If you're new to this, try to put your time into actually learning about these topics and not just blindly repeating other peoples opinions. Please don't say things like "c/c++ is unsafe and should not be used" without understanding it first. I don't think you need 10 years to understand enough to be qualified to comment.…

You took my post as saying "all systems code should be written in C and that should always stay that way because people don't make mistakes". However, that is not at all what I said (also see other replies). What I said was that one should not blindly make the opposite (false) reverse assumptions, which are that "code should not be written in C/C++ because they are 'unsafe'" or "all code written in 'safe' languages i…

The big safety wins from Rust for me are things like the type system disallowing iterator invalidation, the type system handling resource releases, iterators making bounds checks a lot more affordable, the shared immutable/unique mutable distinction, the ability to encode that something can't keep a value somewhere accidentally, type system enforced thread safety, and others in that category.

Why would I need a good understanding of C++ to consider these built-in facilities or the ones that just happen due to the type system as safer?

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

#97

Post by pjmlp »

fnl wrote: post #90
pjmlp wrote: post #88

Earlier quoted context omitted.

I kind of agree with you, back in the day during the C vs C++ flamewars, I was always in the C++ side, and still am if you follow my comment history. However a big part of the problem, which you kind of refer to, when talking about lack of understanding between C and C++ differences is that, at least on enterprise space, many use C++ compilers for writing what is mostly C-like code. Do you know why most MFC classes h…

I completely agree with you on that take. However, if you accept that take, I see little chances of convincing management in such a company to switch to a new, fledgling language - even if it were much safer to use. If anything, your hopes might be that you can teach their teams to use modern C++ and accordingly and slowly massage their code-bases into a more up-to-date state... Ie., (not the least due to those vast…

Hence why I mostly focus on Java, .NET and C++, and tend to comment that regardless how great Rust might be, it will take several years for any relevant uptake.

Just to show how bad it is to move those big enterprise ships, only now in 2017 has BMW moved from C to C++14, for their car platform.

https://fosdem.org/2017/schedule/event/succes_failure_autono...

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

#98

Post by ccommsxx »

phaylon wrote: post #96
ccommsxx wrote: post #83

Earlier quoted context omitted.

You took my post as saying "all systems code should be written in C and that should always stay that way because people don't make mistakes". However, that is not at all what I said (also see other replies). What I said was that one should not blindly make the opposite (false) reverse assumptions, which are that "code should not be written in C/C++ because they are 'unsafe'" or "all code written in 'safe' languages i…

The big safety wins from Rust for me are things like the type system disallowing iterator invalidation, the type system handling resource releases, iterators making bounds checks a lot more affordable, the shared immutable/unique mutable distinction, the ability to encode that something can't keep a value somewhere accidentally, type system enforced thread safety, and others in that category. Why would I need a good…

I don't think you need a good understanding of C++ to appreciate these features per-se. Only if you want to make a statement like "X is an improvement over C++ because of these".

For example, enforced const-ness/immutability, option types and automatic ressource management (RAII) are also already standard in modern/best-practice C++ code. In general I agree that there are a lot of nice languages features that rust currently has which would also be nice to have in the c-family languages.

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

#99

Post by fizixer »

> ... for over ten years my main job was developing and reviewing C++ code ...

> I cannot consistently write safe C ...

When you learn the difference and have spent over ten years on a C-only project and still have the same opinion, I'll take you a bit more seriously.

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

#100

Post by alok99 »

I'd be interested in trying an online coding exercise like the one he mentioned. I've definitely fallen into the trap of thinking that my code was robust because it worked for my specific use case (and no one tried to break it). Now I feel much more skeptical that my code works at all.
Post reply on HN