3 ms·
[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
by akavel 9y ago
[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.
- FRex 9y agoI 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.
- AnimalMuppet 9y ago> 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.