Hacker News Reader

Comment by w8rbt | Hacker News Reader

If you are really worried about the security of old C code, then the safest, most portable thing to do is re-write in modern C++. This is sane and doable in a short period of time. Rust is not.

View on HN

Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. (See maybe SQLite. Seen as one of the pinnacles of crazy pedantism in C. Also, see the article about errors found recently in SQLite with fuzzing!) But with C++, it's just impossible for a human. It's too big, too quirky, too big, too wide, too deep, too tricky, too big, too complicated, and also too huge. And purposefully (sic! for performance) sprinkled with UB, which means barbed fences, trip-wire mines (to boost your in-flight performance), and hidden pit traps. Writing C++ code longer than a few lines without UB is humanly impossible. Sorry. And that's just about UB, because it's the most unpredictable thing; but there's still exception safety, for example, which you also should be doing, which can "only" spoil your code's logic (and then, obviously, go on writing over random memory, but that's nothing uncommon for us C++ers). Is every line of your C++ codebase exception safe? Yeah, sure. Good luck. And "modern C++" only means more C++. Because backwards compatibility. Unless at some point some quest for a "safe subset of C++" finally gains traction, which may maybe bring back some sanity. I do really hope for that.

A personal opinion from a person who loved C++ for quite some time, before diving deep enough to realize how dark is the abyss.

> Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly.

Why the sarcasm?

I'm afraid I was not being sarcastic. Sorry. This is a totally honest and dead serious opinion from a long time C & C++ user. ("stars aligning" here means "you must also have luck". As I said: see SQLite.)

Basically exception safety is a solved problem in Modern C++. If you use RAIIike it was meant to be used, exception safety is not that big a deal.

True, I guess, for "business logic"-y classes. Not true at all for data structures, particularly those that are templates.

How is it not true for data structures? Even templated ones?

For serious exception safety, you have to be able to prove that all invariants all the code of your class relies on are kept between every 2 subsequent lines of your code in that class. Because exception can occur everywhere. And actually, I oversimplified, because often you must also know what happens in each and every operator you use, including implicit casting operators, and also in your destructors and constructors, including implicit ones. Each of those may or may not throw, and each of those may have some internal state, or modify your state in unexpected ways during an exception. RAII gives you primitives which you trust are written with exception safety w.r.t. their inner invariants. But you build some code on it, which has its own invariants. Do you prove them between every 2 lines of your code every time you change a line in your code? After I read enough about exception safety, I realized how hard it is to keep watertightly.

do you mind me providing a bit personal suggestion? When you've began resorting to play of words like 'barbed fences, trip-wire mines...' instead of providing concrete proof/examples in your post, you've already lost your argument.

> Writing C++ code longer than a few lines without UB is humanly impossible.

Do you want me to provide one for you? Because that will definitely change your definition of 'humanly impossible' tasks and might also bring you back from realms of using comically bad phrases..

Ok, please let me ask you a question: have you read all the fragments of The ISO C++ Standard regarding undefined behavior? I have not, but I've read enough fragments/quotes to raise hair on my back and show me how many assumptions I had and assumed safe were subtly wrong. If you have not read all the fragments, you by definition don't know enough about UB to protect against it! Sorry.

I struggle to imagine how you could be more wrong. C offers minimal if any possibilities for writing safe code, while C++ offers many.

Anybody who has the faintest clue about both languages should know that.

I actually feel that C++ memory management is less safe than that of C, because smart pointers provide the same opportunity for use-after-free while being much more opaque about when the destruction occurs. The rules about when destructors of temporaries are called in the evaluation of expressions are subtle.

I'd be happy to discuss an example, because right now the idea that smart pointers are opaque about destruction is unfortunately too abstract for me to give a helpful reply to.

Consider situations like this: https://stackoverflow.com/questions/17362673/temporary-lifet...

It's undefined behavior, despite not calling free anywhere. Replace with std::string and it could be use after free. In C, UAF wouldn't happen that silently for heap memory.

A similar example was posted by matthieu_m on Reddit a while back, but that's still not worse than C, even if it's an unfortunate gap in compiler diagnostics.

From my POV compilers should warn that this code is potentially dangerous. My rule is: never return a reference or pointer from a function to something whose lifetime you don't have control of.

It's worse than C because you can't have UAF in C without explicitly calling free (or a function that transitively calls free). In C++ freeing is implicit.

Do you even explicitly free() a RAII-managed pointer? If yes, why?

No, and that's the problem. Free can effectively be called invisibly, causing UAF.

C is kinda small enough, that I imagine one can maybe have some chance at trying to hold the whole of it, including all nuances/warts, in one's head. Like, maybe even actually write a compiler for it. (See e.g. Dennis Ritchie, Fabrice Bellard.)

With C++, good luck even reading and understanding The ISO C++ Standard. Not to say fully internalizing all possible interactions between all nuances. I presume not all of them may even be truly 100% fully fleshed out and explored in The Book. As to writing a compiler - even just writing a parser for C++ is famously super hard!

> C is kinda small enough, that I imagine one can maybe have some chance at trying to hold the whole of it, including all nuances/warts, in one's head.

Anyone that is able to keep in mind the documented 200 cases of UB is my hero.

Fastest to develop, yes. Portable, yes. Safest? Well, only in as much most of the errors will be blamed on the programmer for not doing the correct modern C++.

I mean, seriously, understanding the borrow checker is nowhere near as hard as understanding this: https://akrzemi1.wordpress.com/2013/10/10/too-perfect-forwar...

There's a No True Scotsman aspect to C++ advocacy. Anything that is obviously dumb either is because the programmer did it wrong, because it belongs to the ever-growing list of features you avoid or "doesn't come up that often".

Why not Rust? Given that you aren't very familiar with niether C++ nor Rust, I'm not convinced that C++ is saner or faster.

Or just rewrite it in modern C. This is sane and doable in a short period of time. You just have to make sure it's modern C.

(no true Scotsman)

> Or just rewrite it in modern C. This is sane and doable in a short period of time.

What do you call modern C?

Well, anything that does not support the point I am making is not modern C.

I think his comment was facetious. I think the clue is "no true scotsman," which is a type of fallacy. I think the point is that it's assumed to be better because of the use of "modern," and that it's only valuable if it's rewritten in something modern. Perhaps it's a joke about how old code is actually fine, and that people who get excited about the cutting-edge technology could chill a little bit. Maybe it's just a mockery of the previous arguments.

No true Scotsman:

"We found a terrifying vulnerability in your codebase. You should rewrite it in modern C++."

"OK, done!"

"We found a terrifying vulnerability in your codebase. It must not have been modern C++!"

same question applies to C++. every new version of C++ is the modern version for a while…

Isn't Go pretty much the modern C, with additions in concurrency?

It's garbage collected. So, no.

No, not really. Go left a lot of C behind (pointer arithmetic for example), while also being garbage collected and having modules instead of header files. Coincidentally, while being touted as replacement for C and as the "language of the server", most of its converts come from python, ruby, and node.js evironments.

Perhaps he means C11? The most recent standard (ISO/IEC 9899:2011).

https://en.wikipedia.org/wiki/C11_(C_standard_revision)

As long as it possible to run the same old C code inside your "modern C++" rewrite, you might have ported the security holes to C++. The problem is, C++ is far to compatible to C here. The idea of all "safe" modern languages is, that unsafe constructs are simply not allowed by the compiler. Why not let the compiler do the checking work vs. hoping that the human programmer didn't miss a check?

Reply on news.ycombinator.com