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.

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.

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.

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?

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.

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.

[edit: ah, potentially my best argument regarding UB, that I thought of in another reply in this thread: so, please tell me now, have you read all the fragments of The ISO C++ Standard regarding UB? Because if not, you by definition don't know when you may be committing UB! :) And what I can tell you, is that I have not read all of them, but I have read enough of them to raise hair on my back and make me absolutely doubt all C++ code I've ever written, or would possibly ever write in future.]

Please note I didn't say a word about Rust here :) That's your overinterpretation. First of all, I never actually used Rust; from what I've seen, I feel it has some potential and good ideas; but OTOH, I also get the feeling that one is forced to use 'unsafe' blocks from time to time anyway, so there's still some area for self-inflicted danger. Even standard library has some errors found from time to time and reaching the news. Also the compiler is new so not very much battle proven yet. Also I'm somewhat uneasy about the fact, that Rust seems to be quite a big language already, and still growing in complexity. Not sure what's the solution. But C++, as it is now, in my opinion is most certainly not one.

I was employed in a big corporation and working on a moderately big C++ codebase. It totally had UB, overwriting random memory, exceptions, etc. It was common knowledge in the operations that the app crashes randomly lots of times a day and has to be restarted automatically, to the point of this being considered non-issue. Virtual inheritance was avoided; don't recall non-public. Pointers to members, suppose yes. Templates - oh, tons of them, and growing. The company actually has super smart C++ programmers (and I mean it!), submitting proposals to the C++ committee and having them accepted. Now, note the Brian Kernighan's quote about debugging clever code. I once debugged a somewhat more -often-than-normal crash. It ended up proving to be a data race. It was a fun experience, though at times totally depressing. UBs were so common during this debugging that I simply ignored them, or I'd go insane. But when I look at how easy it is to detect and debug races in Go, and how still I have to be careful to avoid races there, and still make them from time to time, I know there are tons of them sleeping undetected in any multithreaded C++ code. And we had valgrind etc (though it was rarely used, as it slowed the app to a crawl). Now, all the perfect "modern" or "subset" C++ you claim is so flawless (for whatever actual definition of "modern" you'd try to choose) is never fully enforceable, because it would be too strict or "not performant". Plain ugly non-modern C++ will spill, I don't believe you'll avoid it in any corporate environment. Maybe in an idealized open-source side project, in theory.

As to rm, bash, zsh, Windows Explorer's right click, etc - I'm sure they are broken! Those are the so called "bugs" you hear about so often. I didn't once say I won't use those tools. I only wish they weren't so buggy and unreliable... On the other hand, worth to note that there's always a random cosmic ray from time to time, or a bug in processor's microcode. So even Rust or Idris may not protect you at all time, I suppose plain old asserts may be more reliable as a last line of defence.

And back to your first point: again, "you have to delete ASAP" is a strawman from you here. But anyway, Windows totally has tons of security bugs, see all the NSA exploits, recent ransomware, Pwn2Own, etc. Though they seem to have gradually learned since the Win95 and XP days and stuff is slowly improving. Linux, absolutely has bugs and security holes! Linus is famously not treating security holes as serious bugs, isn't he. Filesystems are buggy as hell! SQL database engines have to go to great lengths to try guaranteeing atomicity and reliability of writes over existing filesystems. Drivers, woohoo, those are especially famous for being buggy and of low quality standards, on whatever OS you like. But I never said to not use them. But you can't stop me from wishing and hoping we have them safer and more reliable some day. And maybe hopefully helping to do that too. Stuff like OpenRISC, seL4, GenodeOS (C++! that part makes me uneasy actually, unfortunately), Nix (again C++), maybe even QubesOS, give me some glimmer of hope for a more reliable future.

> It totally had UB, overwriting random memory, exceptions, etc. It was common knowledge in the operations that the app crashes randomly lots of times a day and has to be restarted automatically, to the point of this being considered non-issue.

Most fundamentally, that's a corporate culture issue. That should not be regarded as normal in any sane environment. (And, yes, such environments do exist.)

> The company actually has super smart C++ programmers (and I mean it!), submitting proposals to the C++ committee and having them accepted.

But not thinking it's a problem when the app crashed multiple times a day? That sounds like architecture astronauts, not good programmers.

> I know there are tons of them [data races] sleeping undetected in any multithreaded C++ code.

No. I've worked on real-time multithreaded code that had no data races, thanks to judicious use of mutexes. (Now, I can't prove that, and you could argue that they're there, and I just don't know it.)

It's possible to do much better with C++ than what you experienced - to write solid stuff that doesn't crash every day, still less multiple times a day; to write multithreaded code that isn't riddle with race conditions; and so on. Mostly, what it takes is a team (or corporate) culture that insists on quality code, from start to finish - good design, good development, good testing and debugging.

I am not saying C++ and all the stuff listed is always safe, just that it's good enough for daily use, including professional use where lives are on the line. As I said before, you used extreme words and made C++ sound like Java applets - something no one ever should use nowdays outside of truly exceptional circumstances (a.k.a. not something as widely used as OSes, browser and the HotSpot JVM).

I'm sure you have seen BS codebases in Java, C#, PHP, Python, etc. as well, I've seen weird interactions with GC in WildFly (I can't comment more because I'm not a Java programmer), spooky action at a distance, globals, using one huge table in a DB to store everything thus missing the point of a relational DB, etc. all in non C nor C++ and it'd not help these things if they were in Rust.

Not all bugs come from the language itself either, some are just true programmer errors. I just google for PHP SQL tutorial (not an English one) and the result is of course pasting input together with SQL to form a query, 0 escaping... Sony had a leak like that. Many Windows issues are pure ignorance like having SMB (that turned out to be buggy, but still) running by default, similarly stuff like misconfiguration, default passwords, Apple's goto fail won't be solved if people are copy pasting code and formatting it badly (unless Rust enforces that, I'm not sure, I don't know Rust yet). Rust will not prevent these kinds of mistakes (maybe the last one if the compiler itself detect inaccessible code and maaybe the SQL one if it marks the variable from user input unsafe at first and cascades that through the function calls to see if it was pasted and passed to SQL) unless it has extremely deep understanding of what's going on.

Additionally, despite all the bugs in Windows there (sadly) wasn't a huge exodus to Linux (which too has tons of bugs and is in C and has lots of programs in C++), it just works "well enough" despite the flaws, there no disaster hanging over our heads.

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

I'm not sure I agree with the amount of hyperbole in the original post, but you must be joking if you want to claim that browsers or OSes are "safe" in the Rust sense of the word.

Use after frees and numerous other memory bugs are discovered all the time in C/C++ programs (including kernels and browsers). This isn't an imaginary problem. Then combine multithreading and you've got a whole extra level of possible issues. Rust does solve many of these problems, and you can prove it does so mathematically.

I understand why people don't like the use of the term "safe" because it feels like a value judgement. But I think people's egos really should be a bit less fragile when discussing language choices.

> Then just delete your entire OS or at least your browser, don't force yourself to use C and C++ software.

With RedoxOS you actually could do that in the near future once it supports some more hardware. The kernel and entire userland (with graphics) is written in Rust. And they did it in 2 years. If nothing else you have to admit that there are some very talented engineers using Rust.

Your point being exactly what? Don't put words in my mouth because I never claimed C and C++ are as safe as Rust, just that they are good enough for millions, including you, to rely on daily with their lives and that Rust itself relies on some C++ (LLVM). I'd even say that yes, C is the least friendly and most spartan language and C++ is the most complex and hard language that are in wide use nowdays but that wasn't the OP's claim. The OP's claim was ridiculous and on the level of opinion people have of Java applets ("totally unsafe", "useless", etc.). These people who have such opinions of them don't run them in their browsers so you should not run any C or C++ on your machine either or you are clearly overdramatizing.

Mathematical provability and technical excellence has sadly little to do with adoption - see where JavaScript, Erlang, Haskell, OCalm, Modula, etc. ended up and tell me every language got what it deserved based on its own merit.

Fanboying over Rust and RedoxOS (it being impressive or not is besides the point) won't fix all that "doable if stars align C" and "humanly impossible C++ that has UB even after few lines" code out there in the government, power plants (including nuclear), infrastructure, stores, embedded, banks, ...

Egos have nothing to do with it. I dislike JavaScript, Java and C# personally (not for any technical reasons but due to my tastes) but if I've seen someone saying the are useless and everything written in them is broken I'd call BS. I'm similarly fond of Free Pascal with LCL for personal GUI toys but if someone said it'll take over the world and destroy Qt and GTK+ behemoths I'd also call BS. Hell, I'd defend your precious little Rust if someone said something stupid about it.

There's factual critique (which I have lots of myself and I don't recommend C or C++ to new hobbyist programmers but Python3), there's personal taste (that you mustn't camouflage as technical opinions) and then there's pedal to the metal "I hate the language so it's totally useless and no human can use it" BS like the OP's comment.

Rust supposedly targets C and C++ programmers so it shouldn't be acceptable to shit all over their tools and by extension their work, telling them they are stupid for liking these languages and are doing everything wrong as an engineer. The fact that such BS is disallowed in official Rust spaces is really telling of how idiotic and ridiculous it is: https://news.ycombinator.com/item?id=14755394

Regarding my initial outburst, I'd like to clarify that it was specifically against a comment claiming that rewriting C code in ("modern" or not, whatever) C++ is the safest choice if someone is worried about security of a C codebase. I didn't actually even say a word about Rust. The C vs. C++ claim there was already enough to make me want to cry loud.

Ah, but I never called to delete any C/C++-based code! That's a strawman from you here. Also, especially I didn't say it's impossible to write anything substantial and/or useful in C++, oh, most certainly it is! But truly, I did and do claim it's humanly impossible to write anything safe in those. As to doing a programmer's job wrong, sorry if you got such impression. Wasn't my intention. C++ is powerful, and in many cases, the gains of using it overpower the risks. As to endangering people, now that's a different topic, and there are measures to protect people possible even in case of unreliable systems. But anyway that's really niche, your Windows/Linux/OSX laptop/PC won't really endanger people until you start hitting them with it, to first approximation. In the other case, like medical software, logic bugs can be I suppose orders of magnitude more dangerous to people than UB-related etc. bugs.

I'm not saying C++ kills people. But I am saying it is producing inherently buggy software, on some level. I'd say it this way: improvements that Rust, Idris, Haskell & many other new languages (and also some old ones, actually, like reportedly Modula, Ada, etc.) try to bring to the table, are similar to what procedural programming or type systems brought over assembly. Resisting those improvements is... strange to me.

[edit: I noticed I wasn't allowed to reply to some comments downstream a while before. I think this may be some kind of a signal for me to just STFU and drop the ball; even if not, I decide to just treat it so, I've said more than enough words already probably. Actually, biggest outburst of my posts on HN ever. I'm starting to think I might be having some kind of a PTSD w.r.t. C++. Anyone knows of some good therapy centers for recovering C++ veterans? :) ]

You can write large C++ programs that are quite safe, using only higher level abstractions (no pointers or explicit memory management). This doesn't require any fancy new C++; code written to C++98 (first ISO C++ standard) will do it just fine.

For exmaple, in C++, we can put two strings together to make a new string without worrying about whether we have a buffer large enough to hold the result, and whether null termination is ensured and so on, or whether or not the original source strings are damaged in the process (they are not), or whether that memory will disappear when we return to the caller. It's just str1 + str2.

I'm no C++ advocate, bu the fact is C++ code can look like a scripting language and be safe like one. C++ also has tools for isolating and managing the C-like semantics that a C++ program might contain.

So even to clump together C and C++ as "C/C++" is not well considered. There isn't a "C/C++" language. If you post a message about C/C++ in the comp.lang.c newsgroup, put on your flame-proof asbestos underwear first.

Higher level constructs like iterators, references and smart pointers are all relatively easy to misuse. It is definitely possible to have safe abstractions like std::string's + and they're one reason why C++ is an improvement over C, but there's still many other dangerous edges that are nearly impossible for a human to keep track of at scale.

There are things in the C++ standard library that are not very well designed, yes.

For instance, erasing from some containers causes undefined behavior if iterators that were created before the deletion continue to be used.

Some of the various smart pointers for managing memory are not so smart; they have been redesigning new ones and deprecating old ones so many times now. It used to be "your code isn't exception safe: use auto_ptr, you dolt!". Then, "you idiot, don't use auto_ptr, use this instead" and so on.

You can avoid all that by defining your own classes that do just what you need, use only the safe stuff from the standard (like the aforementioned strings) and write yourself a perfectly memory-safe, leak-free C++ program.

Even the modernest pointers unique_ptr and shared_ptr are dangerous (use after free/move and, e.g., ease of data-racing in the data, respectively). The problems with them are relatively fundamental to C++ and its idioms. The classes you define will need to avoid using fundamental C++ features like references too: anything pointer-like can lead to problems (including `this`)

The "you (and the standard library, including the completely new parts) are holding it wrong" defence is tired, when it is so ridiculously easy to do so: it is okay and important to acknowledge that a tool is powerful but also has a pile of hard-to-avoid sharp edges.

I fully agree, but you cannot oblige everyone that touches the code to have the same care, and so the typical "C with C++ compiler" idioms sneak in, thus decreasing overall safety.

This is specially the case in the majority of enterprise software that doesn't use any kind of static validation tooling, or CI builds.

> you cannot oblige everyone that touches the code to have the same care

If you can't enforce that certain rules be enforced in a C++ program, you also can't enforce that someone won't sneak C++ modules into a code base written in another, safer language.

> doesn't use any kind of static validation tooling, or CI build

Or, also: a review tool for rejecting stuff that is against the project's explicit coding guidelines.

> you also can't enforce that someone won't sneak C++ modules into a code base written in another, safer language.

In Java and .NET projects you can easily ensure that, and that is a common scenario in some of our customers.

The machines are provided locked down by IT with the project sanctioned tools, including the configuration for in-house Maven and NuGET repositories.

No native code compiler gets installed, servers are configured to disallow unsafe code.

Any library not available requires a change request to the IT team.

With that environment and people, we could easily enforce C++ rules in the same way.

Stuff you don't want in C++ code can be rejected by a pre-commit hook which scans code. That header can't be #include-ed, that crazy operator can't be used, etc.

Also, with open source compilers, you can implement your own warnings. (Been there, done that; in the role of an embedded distro/kernel/toolchain person some years ago, I hacked g++ with custom warnings).

If there is something we don't want in C++, and it doesn't "grep" well, we may be able to diagnose its presence in the compiler and treat that as an error.

Not really, the part you are missing is that it is easier and cheaper not to have C or C++ compilers available at all.

No, what I mean that if those same people were running a C++ shop rather than a Java shop, they could be equally and just as effectively draconian in their enforcement.

Ah I get your point, but static analysers and sanitizers aren't able to find all unsafe issues, specially if binary dependencies are involved.

This is why on Solaris there is OS support via SPARC instructions to enforce bounds and valid pointer use, for example.

That's actually why I call BS on anyone who says "C/C++" while claiming to be a (former) C++ high level user (dabbling in it doesn't count, I dabbled Java, C# and PHP but it's not even on my CV because I don't consider myself anywhere near production level in them) and try to use "C and C++" myself. See: http://www.stroustrup.com/bs_faq.html#C-slash

The call for removal of C++ is implicit or do you now say we keep extremely unsafe (in your eyes) software around and put our lives on the line? Lives and livelihoods do depend on C and C++ software in nuclear, medical, governmental, financial, etc. and somehow millions are not dying due to all this unsafe software. No software is 100% safe, even Erlang (another dear of HN but one that is enjoyed in a more civil environment than the "Go Rust, Fuck C++") is just "nine nines" reliable.

You made C++ sound as bad as Java applets or something similar. Obviously anyone saying Java applets are unsafe, bad, etc. is telling you between the verses to not run any, ever. The words you used were very strong and made it sound like everything is buggy as hell while the bugs are minor and few and far between (relatively speaking, there are lots in some places but your browser and OS is not crashing or leaking your data to hackers on a daily basis, the situation is nowhere near tragic).

Saying C and C++ are unsafe basically shitted on every programmer ever that picked them for anything important, kernel makers, browser makers, server makers, languages VM makers - all idiots, endangering people and property, writing unsafe software!

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?

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!"

<Time passes>

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

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

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.

It's garbage collected. So, no.

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

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

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

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

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?