1. 43
  1.  

  2. 33

    I’ve run into this mentality myself a couple of times, people claim in 2018 that they can write safe C/C++, it’s only those other people that can’t.

    1. 7

      I would claim that 2018 is the best time (yet) for writing memory-safe C++. We have tooling and paradigms now where we don’t need to rely on raw pointers and can make use of things like shared_ptr and unique_ptr. We can utilize the vector class which gives us OOB write protection (via the vector::at method) . We can even look to the design decisions made in Rust and see they draw their roots from modern C++ (think RIAA). All the protections of Rust already exist in C++, and are distinct enough that tooling can catch when developers don’t use them.

      1. 20

        I agree about it being best time to write safer C++. Ill add C, too, given all the analyzers. Empirical evidence Gaynor references show vast majority of C/C++ code fails to be safe anyway. So a safe-by-default option is better to use with unsafety turned on selectively when necessary.

        Also, the key aspects of Rust’s memory safety come from Cyclone language. It was a safer C with some temporal safety among other things. Clay was another which had linear and singleton types.

        1. 15

          All the protections of Rust already exist in C++

          Unless you are claiming C++ has a way to ensure data race freedom, this does not seem true.

          1. 10

            Smart pointers have been around for more than a decade (in Boost before they got into std::), and STL has been around for ages of course. From the memory safety perspective, the tools have been around for a long time. Perhaps the issue is that none of these things are mandatory.

            1. 4

              Halfway there: C++ was built on unsafe-by-default foundation, C, with good protections added that also aren’t mandatory. It evolved from there in a lot of ways I didnt keep up with. I just know that plus its parsing/semantic headaches gave C++ a brutal start if goal was safety on average or high assurance.

            2. 9

              (via the vector::at method)

              Which you have to remember to use instead of the far easier nicer looking []. I’ve seen v.at in a C++ codebase exactly once in my life. As usual, the default C++ is unsafe.

              We can even look to the design decisions made in Rust and see they draw their roots from modern C++ (think RIAA)

              True but not sure of the relevance.

              All the protections of Rust already exist in C++

              They most certainly do not.

              tooling can catch when developers don’t use them

              There are no tools that I’m aware of that guarantee an absence of bugs in a C++ codebase. I’ve used most of them. Bugs still happen. Bugs that don’t happen in safer languages.

              1. 9

                All the protections of Rust already exist in C++

                I’m not sure that’s entirely true, but I could be wrong. I agree with what you are saying about RIAA, but a few other things pop to mind:

                • Rust tries really hard to ensure you have either only immutable references, or a sole mutable reference. This prevents the old “iterate over a collection and mutate it” problem.

                • It also forces you to think about sharing semantics across threads (i.e. Sync trait).

                • In Rust you can design APIs which “consume” their parameters. i.e. you pass ownership to a callee, and it never hands it back. This is useful for scenarios where you don’t want the user to try and re-use a conceptually finalized data structure. Perhaps reuse of the structure could be unsafe for example.

                I’m sure there will be other examples. And I’m sure the proponents of Rust will provide those in more comments ;)

                Maybe you can do these kinds of things in modern C++?

                1. 6

                  Problem with C & C++ is not only about memory safety. Are you 100% sure you have absolutely no chance of a signed int overflow anywhere in your codebase?

                  1. 15

                    Compile with -fwrapv to instantly unlock the same behavior as rust.

                    1. 5

                      To get the K&R C behavior not the house-of-horrors C standard.

                      1. 3

                        Or better, -ftrapv to trap even errors that Rust won’t catch. (I don’t understand why this wasn’t made the default behaviour in Rust, to be honest; the performance hit should ultimately be negligible, and they already make some choices for safety-over-performance).

                        1. 4

                          The reason it is not default in Rust is that performance hit was not negligible.

                          1. 0

                            Got some numbers? Part of the problem is probably that the code generator (LLVM) doesn’t handle it very well; but basing a language decision on a current limitation of the code generator doesn’t seem wise. (Especially if it’s a choice between “fail to detect some potentially critical code issue” and somewhat reduced performance).

                            1. 5

                              I don’t have the reference for Rust handy, but NIST Technical Note 1860 is one good reference. To quote the abstract:

                              We performed an experiment to measure the application-level performance impact of seven defensive code options… Of the seven options, only one yielded clear evidence of a significant reduction in performance; the main effects of the other six were either materially or statistically insignificant.

                              That one option is -ftrapv.

                              1. 1

                                That report is specific to GCC, though, which has worse overflow checking even that LLVM.

                                “In practice, this means that the GCC compiler generates calls to existing library functions rather than generating assembler instructions to perform these arithmetic operations on signed integers.”

                                Clang/LLVM doesn’t do that. Needless to say, it explains much of the performance hit, but not how it would affect Rust. I’m curious about what the real numbers do look like.

                              2. 1

                                (actually, having done some recent ad-hoc tests LLVM seems to do ok, mostly just inserting a jo instruction after operations that can overflow, which is probably about as good as you can do on x86-64. I’d still like to see some numbers of how this affects performance, though).

                        2. 2

                          I agree memory safety is not the only kind of security bug, but it is the focus of this article, which is why I focused on it in my comment.

                      2. 4

                        And how do you know they’re wrong?

                        We see evidence all the time. Easily preventable bugs in old software everybody used but nobody wanted to make good. Bugs that would’ve been obvious if people had looked at compiler warnings or run a static analyzer, but nobody did..

                        1. 24

                          And how do you know they’re wrong?

                          I don’t know about @szbalint, but I know they’re wrong because of ample experience with people who think they can write safe C code and can’t. I literally have never met or have worked with an engineer I’d trust to write C code, myself obviously included.

                          I’ve been compiling all C and C++ code with -Wall for at least the last 15 years, and the last 10 with -Wall -Wextra -Werror. I’ve used free and paid-for static analysers on production code. Tests, extensive code reviews, valgrind, clang sanitizers, the lot.

                          The end result were bugs, bugs, and more bugs, many of them security vulnerabilities. This problem isn’t solvable with developer discipline and tools. We’ve tried. We’ve failed.

                          1. 2

                            Has your experience with D been much better? I’ve been able to segfault D because I didn’t realise that SomeClass c; generates a null pointer. I really wish the language were modified to make this impossible without some extra attributes like @trusted.

                            That’s the only way I’ve managed to really “crash” D, though. The rest of the time I get pretty stack traces at runtime whenever I mess up, much more controlled and predictable error-handling.

                            1. 1

                              Has your experience with D been much better?

                              Vastly so.

                              I’ve been able to segfault D because I didn’t realise that SomeClass c; generates a null pointer.

                              That’s not considered an issue in D. Variables are all default-initialised so you’ll get a crash at the point where you forgot to assign the reference to a new instance. Deterministic crashes in the face of bugs is a good thing.

                              1. 1

                                A segfault is a pretty obscure thing, and I’m not sure it’s even exactly “deterministic”. Are all arches guaranteed to react the same way to dereferencing a null pointer? It’s not like it’s raising a D NullPointerException, if such a thing even exists, so I don’t get a stack trace telling me where the problem is, unlike every other D “crash”.

                                I still don’t understand why making this segfaulting easy is desirable. It feels like an obvious rake to step on.

                                1. 1

                                  A segfault is a pretty obscure thing

                                  To a scripter, maybe, but not to a systems programmer.

                                  and I’m not sure it’s even exactly “deterministic”

                                  Some are, some aren’t. The deterministic ones are of the good variety. Always crashing because of an unitialised reference is ok. Getting a segfault somewhere else in your app isn’t.

                                  It’s not like it’s raising a D NullPointerException, if such a thing even exists

                                  It doesn’t exist, or rather, its version is to just segfault.

                                  so I don’t get a stack trace telling me where the problem is, unlike every other D “crash”.

                                  % coredumpctl gdb
                                  % bt
                                  

                                  If you’re not running systemd then run the program again under gdb. Since it always crashes in the same place you’ll get the same result. If you’re on Windows you open the debugger right there and then and look at the backtrace.

                                  It feels like an obvious rake to step on.

                                  It isn’t, it always takes me 30s to fix.

                            2. 2

                              I don’t know what your use involves, but sometimes using e.g. Coverity is not much better than never using it. All those things have to be done in the context of a comprehensive build and test system and always done on every checkin. And there is no substitute for good programmers with solid education. I have met a number of really excellent C programmer who produce solid, trustworthy code.

                              And, as always in such discussions, none of these assertions make sense without a “compared to”. People write unsafe C code, compared to which people who write what?

                              1. 2

                                using e.g. Coverity is not much better than never using it

                                Not in my experience.

                                And there is no substitute for good programmers with solid education.

                                Few and far between.

                                I have met a number of really excellent C programmer who produce solid, trustworthy code.

                                I have not. And that includes meeting compiler writers and C++ luminaries.

                                People write unsafe C code, compared to which people who write what?

                                To people who write code in Ada, Rust, …

                              2. 1

                                The end result were bugs, bugs, and more bugs, many of them security vulnerabilities. This problem isn’t solvable with developer discipline and tools. We’ve tried. We’ve failed.

                                Then why is it that when the bugs that relate to language level issues are dissected in the public, they nearly always seem like they’d be prevented by discipline & disciplined application of tooling?

                                1. 4

                                  Even the best programmers have an error rate. Much lower than novice programmers, but it’s still there.

                                  1. 1

                                    You are stating the obvious here.

                                    The question is, why aren’t these errors being caught when it is so easy to do?

                                    1. 6

                                      The nature of the tooling seems like a prime candidate answer to that question. In C and C++ you often need to opt into constructs and static analyses in order to guard against memory safety bugs. Just look at all the tortured defenses in this thread alone. It’s some combination of “oh just use this particular subset of C++” all the way to “get gud.”

                                      In memory safe languages the tooling generally demands that you opt out in order to write code that is susceptible to memory safety bugs.

                                      It’s just another instance of “defaults matter.”

                                      1. 0

                                        I think we’re going in circles here. None of what you say is evidence that people can’t write safe code. You’re just saying they (most of them) won’t, which isn’t the contentious point.

                                        1. 5

                                          Seems like a distinction without a practical difference. You asked a question, “why aren’t these errors being caught when it is so easy to do,” and I answered with, essentially, “maybe it’s not as easy as you think.” I proposed a reason why it might not be easy.

                                      2. 4

                                        The question is, why aren’t these errors being caught when it is so easy to do?

                                        It isn’t easy. If it were, they’d be caught. The litany of security vulnerabilities everywhere shows us that we’re doing it wrong.

                                        1. 1

                                          Right. Why not?

                                      3. 2

                                        Did I claim developer discipline wouldn’t prevent bugs? What I’m claiming is that it’s humanly impossible to manage that level of discipline in any large codebase. And I’m claiming that because we have decades of experience telling us that it’s the case.

                                    2. 3

                                      You raise a good point. I think anyone who thinks their own code is perfect is wrong, but I can’t prove it. I suppose, also, that it could be vacuously true in the sense that maybe their own code is perfect, but they haven’t written production systems entirely by themselves. Was that what you were suggesting?

                                      1. 2

                                        You raise a good point. I think anyone who thinks their own code is perfect is wrong, but I can’t prove it.

                                        Can you write one line of code that is perfect? Why not two? Why not ten? Why not a thousand?

                                        Even then, there’s a continuum between perfect and unmitigated disaster. I’ll grant you that I don’t really believe in large scale software ever being perfect in a literal sense of the word. Not even bug free. However, I believe there are individuals who can produce safe software in C. And if given enough control over the platform the code runs on, they can lock things down to virtually guarantee that language level issues are not ever going to turn into full compromise (RCE) or secret leaks.

                                        If you need something for a case study, why not take a look at qmail? The fun thing is that the papers and writeups about qmail’s security practices don’t really mention things such as extensive use of static analyzers, fuzzers, and formal verification. Despite that, it has an incredible track record. I think there is much more that could be done to raise the bar.

                                        I suppose, also, that it could be vacuously true in the sense that maybe their own code is perfect, but they haven’t written production systems entirely by themselves. Was that what you were suggesting?

                                        Security costs time and isn’t sexy. Worst of all, you can’t measure it like you can measure performance or the length of the list of features. So even if someone out there is producing “perfect” code, it’s likely that the project goes mostly unheard of. If one were to dig up and point out such a project, people would just call it a toy / academic exercise / “nobody uses it.” People might say they care about security but they really don’t, they just use whatever is convenient or popular. And when you point out the bugs in that, well, developers being developers, they just pat each other on the back. “Dude, bugs happen! Give ’em a break!”

                                        It’s especially bad in any commercial setting, which is why I think it is indeed the case that the people who are capable of writing secure software are, in the end, not doing that, because they don’t get to write an entire production system on their own terms. I don’t think it’s a coincidence that the project I just mentioned is essentially a solo project by one person.

                                        I’m in that boat too, sort of. At day job there’s so much code that’d get you kicked out if it were my personal project with a security guarantee. I’m not at liberty to rearchitect and rewrite the software. The markets opt out of security.

                                        1. 6

                                          Can you write one line of code that is perfect? Why not two? Why not ten? Why not a thousand?

                                          It depends on the line. Perfection isn’t just about the semantics the code has to the compiler, but about how a future reader will interpret it. Even the shortest snippet of code can have subtleties that may not be obvious later, no matter how clear they seem to me today. Concretely, in the 90s, “everyone knew” that system() was a huge security vulnerability because of how it adds to the attack surface, and it wasn’t a big deal because code that was thought of as needing to be secure was hardened against it. But those very same semantics came as a very unwelcome surprise to “everyone” when Shellshock was publicized in 2014.

                                          Lots of vulnerabilities can be traced to people misunderstanding single lines of code.

                                          I very much agree with your point about it being hard to sell security. I think that’s by far the biggest factor in how horrible the current state of affairs is.

                                          1. 3

                                            Wasn’t the key shellshock problem that bash executed environment variables? 99% of these failures seem to come from parsing errors, eval, and convenience components. Why bash designers felt it was good to allow arbitrary functions to be passed in environment variables and then executed baffles me but probably came from feature creep. The same functionality could have been achieved more safely by include/load like mechanisms (not 100% safe either, but easier to lock down) or, better, running other programs.

                                            BTW: Bash scripts are memory safe.

                                            1. 2

                                              It depends on what you see as the most unexpected part of it. The reason it was such an emergency to patch it was that bash was exposed to unauthenticated incoming network connections in the first place.

                                    3. -3

                                      Where are all the safe Rust based applications and operating systems?

                                        1. 6

                                          I mean, so what? The pool of talented systems programmers is vanishingly small, and also going to be dominated by people using C/C++, so its not that surprising that it hasn’t eradicated all the competition yet. And as a sibling commenter pointed out, its doing pretty well for being all of 3 years old.

                                          1. 0

                                            There is a big difference between “has not eradicated the competition yet” and “still can’t point to 5 widely used and superior applications”.

                                            1. 10

                                              how many did python have within 3 years? Or ruby for that matter. How about clojure? None of those had “5 widely used and superior applications” within 3 1/2 years. It was probably a decade before python had 5, maybe a little less for ruby. And you didn’t respond at all to my point about the quantity of systems programmers. Rust is a kind of weird language, attempting to fill a very tight ecological niche with few potential adoptees in terms of actual programmers. I’m not in the least surprised that its still very much in an embryonic state in regards to a community and the works that would flow from that. And, fwiw, Servo and Fuscia aren’t exactly small scale applications, not to mention all of the companies using it internally for whom we have no data/reports other than job board postings.

                                              1. 1

                                                I’m not at all saying Rust is a failure - I don’t find it appealing, but that doesn’t mean anything. But it’s still in the experiment stage. You can declare C obsolete when you have that body of large successful, less buggy, products to point at.

                                                1. 9

                                                  The whole point of the article is that literally decades of experience have shown that it is effectively impossible to write safe secure code in C/C++. The goal in fact is to to declare C/C++ a security nightmare. Does that make it obsolete? Maybe, maybe not. There are options out there that give you far more safety guarantees than C/C++ will ever be able to do.

                                                  Knowing that it is quite possibly flat our irresponsible to use it for any new project where security is important. Oh, and security is nearly always an important concern for a software project.

                                                  1. 1

                                                    Let me try again: To make that claim be anything more than marketing, you’d need some (a) data and (b) some indication that C programs were WORSE than some alternative. In the absence of both, it’s just weak marketing. The evidence seems to show more that it is very difficult to develop large software systems that are safe and secure and, at the same time, find an appreciative audience - no matter what the language. As I pointed out before, until there are significant examples of safe/secure/successful Rust programs to compare with, such claims are just blowing smoke.

                                                    1. 2

                                                      While it’s not as strong a claim as you seem to want, I don’t think it’s incorrect to say that C and C++ in the hands of not superhuman developers tends to result in a whole class of bugs that Rust makes nearly impossible to create. Bugs that have appeared numerous times and continue to keep appearing in critical internet infrastructure.

                                                      It’s purely anecdotal but Rust has prevented multiple use after free, use before initialized, and buffer overrun errors in my own code multiple times just while playing around. It’s a bit disingenuous to suggest that C/C++ don’t have a problem and that Rust which provably prevents most of those problems isn’t a promising solution.

                                                      This isn’t blowing smoke it’s a recognition that there is a problem and possible solution to that problem that doesn’t involve cloning Dan Bernstein and firing all the other programmers.

                                                      1. 2

                                                        I kind of like the idea of cloning Dan Bernstein and firing all the other programmers. It’s a big idea with some verve and panache.

                                                      1. 4

                                                        I agree the comment overstated by saying “effectively impossible.” Really hard with higher failure rates than safe languages would be more accurate. Yet, it seems misleading for you to use Bernstein and Hipp since most people are nowhere near as good at QA as them. Bernstein is also a security genius.

                                                        C defenders countering with the vulnerability results of security geniuses in minimalist apps instead of what average C coder achieves vs average user of safe language isnt a good comparison.

                                                        1. 0

                                                          Hence my quest for examples rather than handwaving. Examples of real applications that are not minimalist. Specific examples.

                                                          1. 2

                                                            Ripgrep? Firefox? The former is shipped and used for search in VS Code, the latter is pretty rapidly moving to using rust where it can to improve performance, and reduce security issues. Just two projects I can name off the top of my head as a non rust programmer.

                                                            1. 0

                                                              The same two projects everyone names and I’m not dismissing either of them. I’m just pointing out that the triumphal declarations of the obsolescense of C and dawn of the Reign of Rust lack sufficient backing. If we just got enthusiastic reports about what people wrote in Rust and how well it worked that would be interesting and impressive. But this overblown marketing stuff is just irritating.

                                                2. 5

                                                  Well, I guess ripgrep qualifies? Hopefully there will be more such applications.

                                                  1. -1

                                                    Ripgrep is interesting. Is it considerably less bug ridden than ag ? Is it considerably less bug ridden than grep?

                                                    https://www.cvedetails.com/product/23804/GNU-Grep.html?vendor_id=72 Well grep doesn’t seem so bad.

                                                    Come on, people need to do better than this.

                                                    1. 7

                                                      Is it considerably less bug ridden than ag ?

                                                      Yes, by a very very large margin across at least a couple different spectrums.

                                                      Is it considerably less bug ridden than grep?

                                                      Unlikely.

                                                      Come on, people need to do better than this.

                                                      Right. Nothing will ever be good enough. This is a classic Internet debate tactic. No matter what example anyone gives you, there will always be a reason to dismiss it. I don’t say that flippantly necessarily. Satisfying your standard (mentioned in another comment) to a high degree is nearly impossible. There will always be differences and variables that cannot reasonably be controlled for.

                                                      It’s totally fine to have high standards that are impossible to satisfy (it’s your choice), but at least state that up front explicitly and don’t be coy about it. And don’t accuse people who are trying to hit a lower standard of evidence as just “blowing smoke,” because that’s a bunch of bullshit and you know it.

                                                      1. -2

                                                        Oh come on: ripgrep is the example I’m given. Yet, grep, written in horrible pathetic C, has very few security bugs. Are there CVEs for ag even? I am ready to be persuaded and I don’t need ironclad proofs - I just want to see a number of examples of complex applications/systems written in XYZ that are significantly better than the standard C versions in terms of security. Until those are available it’s just marketing. Maybe Rust is a brilliant advance that will lead to the creation of highly reliable secure applications - maybe it is not. Without evidence, all this claim that C has been obsoleted by Rust or whatever is exactly that - just blowing smoke. Read software jewels by Parnas, this is not a new problem.

                                                        I’ll give you a good example: the OP makes a big deal about security issues in ImageMagick! Of all things. I cannot imagine that anyone involved in the development of ImageMagick worried about security at all - it was a tool people could use to manipulate images. Now it is being dragged into service as an online utility exposed to the open internet or used on images that come from anywhere and - lo and behold - because of C it’s insecure! Great, let me see a Rust program designed without any attention to security employed similarly and we’ll compare.

                                              2. 1

                                                Quite a few swift based applications out there though, so it isn’t like new languages aren’t being used for things.
                                                Go is quite popular in certain spaces too, for what it’s worth.

                                            2. 22

                                              Just a well cloaked rust plug.

                                              1. 23

                                                Not particularly well cloaked, honestly.

                                                1. 14

                                                  It’s a Rust plug, but I don’t think any of the content is incorrect, is it?

                                                  1. 14

                                                    and? you say this like a rust plug is a slam. It will never cease to amaze me the number of people who think they’re shedding light by pointing out that people advocating a language designed to replace C/C++ is …..being advocated by pointing out the deficiencies in C. No one is being enlightened here with these comments.

                                                    1. 7

                                                      We could test that by running some kind of fuzzer to see how many piles of exploitable bugs we find in C that arent in safe languages. That would test his C point. He’d be wrong if nearly same number of memory bugs or races in languages designed to mitigate them.

                                                      Then, if it’s proven, we have to use one thst fits in C’s domain with active development and preferably significant ecosystem/community. Something he thinks is best one, too. (His bias.) Narrows options way down. Which safe, efficient languages do you prefer he entice C/C++ developers with that match Rust’s memory and concurrency safety? And maybe type-safe abstractions, too?

                                                      1. 5

                                                        pretty sure the author has a side project which is entirely dedicated to doing almost exactly that with AFL. Maybe, just maybe this person is speaking from a place of experience.

                                                        1. 6

                                                          Yeah, he says it’s like shooting fish in a barrel.

                                                    2. 9

                                                      I like how everyone dunks on C but like, we have four or five C alternatives right now that are viable, and numerous compilers and static analyzers and such that are fully capable of catching the bulk of problems that you have in C.

                                                      Not just that, but the problems they list are relatively simple to solve code-wise. Let’s take a look:

                                                      “use of uninitialized memory” -> just use calloc and memset on shit before you use it, and assign all of your variables default values. sparse or cppcheck are quite capable of catching these and will point them out for you.

                                                      “type confusion” -> Literally any sane static analyser will catch this (and I think GCC will too a lot of the time with -pedantic -Wall), but really you shouldn’t assign between variables of different types anyway, unless you’re using a bona-fide conversion function (like, lrint and friends – which will point out bugs for you). Personally speaking I take this further and use large integer sizes and the appropriate size_t and friends wherever possible, anything else is just premature optimization TBH. Besides, the entire point of typedef is to guard against this sort of thing, though. Don’t use void *, use typedef XYZ * typename, and you will very rarely have this bug,

                                                      “use after free” -> This goes under “use of uninitialized memory”. Anything that can be NULL/-1, check it. Set to NULL/-1 when you free. Clang’s scan-build catches a lot of these and sparse and cppcheck are capable of catching the rest.

                                                      Also, from what I’ve read of security literature, most of the vulnerabilities come from things like, not sanitizing your input, allowing larger inputs than you have space for, etc. Those are programming problems that you can have in any language, including Python. While C does give you room to fuck up, it also gives you the tools to NOT do that. Use them.

                                                      Javascript is quite literally a bigger danger with regards to proliferation, pure language idiocy, and fuckup potential, because you actually cannot avoid those parts that are broken (Some of which are generally considered to include, Unicode, and Arrays). People regard C as a loaded shotgun, and then go program in Javascript which has almost an equivalent number of flaws, and which is beyond broken.

                                                      Not just that, but C had and continues to serve a (somewhat debatable) purpose in the embedded world, in kernel development, in drivers, and some other places. Javascript was arguably superceded when Scheme was invented, 20 years before Javascript was born.

                                                      1. 8

                                                        Good points on mitigations being available. On last paragraph, Ada has been around a long time, too, with stuff written in it having less defects. Same with Modula-3 at one point. Newer stuff like Rust can do embedded. There was even a C/C++ implementation done in Scheme for its benefits. D and Nim are contenders with advantages, too.

                                                        C’s time has passed on technical grounds. Best replacement should still integrate well with its ecosystem, though, for practical reasons.

                                                        1. 3

                                                          On last paragraph, Ada has been around a long time, too, with stuff written in it having less defects. Same with Modula-3 at one point. […]

                                                          Oh, indeed! However the main benefit to C as it is, is the lack of linguistic complexity. It’s easy to pick the Right Way To Do Things, there’s very little room for debate, except perhaps architecturally – i.e. where it matters. But in addition to that, the best feature of that linguistic complexity is that a) it’s an easy language to remember, and b) it’s an easy language to hold in your head. It doesn’t require a ridiculously huge parser and it’s ‘easy’ to port (at least, it was, heh).

                                                          C’s time has passed on technical grounds.

                                                          I disagree :)

                                                          The main contender, Rust, not only has a ridiculously bloated stdlib (on part with Common Lisp’s with how lost you can get in it), and AFAIK still produces pretty large binaries. In addition it pushes a specific method of building on you, which really isn’t favourable to me.

                                                          Personally I’d like to see a systems-level language with the syntax of Lisp or Scheme and the philosophy of C, just with a more robust (but hackable) type system.

                                                          1. 3

                                                            re linguistic complexity. There’s many of you that say that. I think you all pick a subset you need with coding style you can work with. That might keep it simple for you. The language itself isn’t simple as I said in the counter to vyodaiken. The people that were modeling and analyzing other languages took something like 40 years to do the same for subsets of C. Even experts like vyodaiken argue with other experts about the language details here on threads about pretty, basic stuff. That doesn’t seem simple.

                                                            re Rust criticisms. Thanks for sharing them. I know Rust isn’t the end all. If anything, there’s still room for stuff that’s more C-like and flexible to help folks that don’t like Rust. I keep mentioning languages like Cyclone and Clay to give them ideas.

                                                            re Lisp/Scheme. There’s two I know of in that direction: PreScheme and ZL. ZL had the most potential if combined with C tooling. Website here. If it doesn’t already, its own implementation probably could be updated to better tie-into popular forms of Scheme like Racket and HtDP.

                                                            1. 3

                                                              re Lisp/Scheme. There’s two I know of in that direction: PreScheme and ZL

                                                              I think bitc was quite promising too (from afar, I’ve never actually played with it). I don’t know what happened to it, its website seems down.

                                                              1. 4

                                                                There was Retrospective Thoughts on BitC in 2012. Mail archive is down too, but you can use Internet Archive.

                                                                1. 1

                                                                  Thanks for that! I’ll have to take out some time to read it, it’s quite long.

                                                                2. 3

                                                                  He was on a row with EROS, COYOTOS, and BitC. Then, Microsoft poached him. (sighs) The best development in high-assurance on language side in recent times is COGENT. They did two filesystems in it. Although paper talks general purpose, O’ Connor showed up on Reddit and HN saying it’s only for stuff like filesystems. He wouldn’t answer follow-up questions about that. So, it’s interesting at unknown usefulness.

                                                                3. 1

                                                                  The language itself isn’t simple as I said in the counter to vyodaiken. The people that were modeling and analyzing other languages took something like 40 years to do the same for subsets of C.

                                                                  As I said, syntactically. The entire C grammar can fit in three pages. The base C library is like 20 pages and fits into the end of K&R next to the grammar. If you want more functions there’s posix, 99% of which is part of the base operating system.

                                                                  You’re right that C-the-implementation isn’t simple. But at that level there are very few simple things, anyway. There are lots of approaches to choose from implementation-wise, for threads, etc. And not to mention the reality of the machine underneath, which doesn’t give a crap about what you think about it.

                                                                  With regards to program verification, you are indeed correct, but I’d argue the main problem with that was that C ended up being subjected to the mutagens of almost every single platform of the 1970s to 1990s, very few of which were standardised. The standards committee ended up having to backwards-support everything. That’s ignoring the fact that in certain cases they make it deliberately more difficult to standardize for the sake of improving optimization, or allowing optimizations that already exist in the wild.

                                                                  I was mulling it over after I wrote the above, and I think it’s useful to adopt a view of C as being forged by the pressures of being quick to write a compiler for, (and therefore relatively simple to understand how something was implemented (see: macro system, standard library – indeed, 99% of K&R is just teaching you C by reimplementing the standard library in tiny snippets of C)), and close enough to the machine that it’s easy to make optimization choices – you can generally (although it’s got harder with more advanced processors), just by looking at the C source, figure out the machine code produced. That’s where C’s power lies, and it’s something that other languages really do not know how to capture.

                                                                  Like, it’s one thing to be able to say, X is better than Y, but C adopts itself really well to showing you why, I guess. And I don’t think we can find a replacement for C until we figure out a language that captures both of those features.

                                                                4. 1

                                                                  In addition it pushes a specific method of building on you, which really isn’t favourable to me.

                                                                  tbh this is my major objection to rust as well. For all C’s build “process” gets maligned, it is very easy to swap in different tools.

                                                                  1. 1

                                                                    However the main benefit to C as it is, is the lack of linguistic complexity

                                                                    Say what now?

                                                                    https://hackernoon.com/so-you-think-you-know-c-8d4e2cd6f6a6

                                                                    1. 2

                                                                      I believe you are replying to the wrong person.

                                                                      1. 1

                                                                        Oops.

                                                                  2. -1

                                                                    However the main benefit to C as it is, is the lack of linguistic complexity. It’s easy to pick the Right Way To Do Things, there’s very little room for debate, except perhaps architecturally – i.e. where it matters.

                                                                    Excellent point and exactly why the Crappy Pascal initiative also known as the ISO C Standard has been so detrimental to C.

                                                                    1. 4

                                                                      I don’t know if you’ve ever worked with pre-ANSI-C code, but given the choice between that and ANSI-C, ANSI-C wins if just for function prototypes.

                                                                      What I don’t like about the standard is the tortured language so that everything from signed-magnitude to 2’s-complement, 8-bit to 66-bit, can be supported. That may have been a valid compromise for C89, but is less and less so as time goes on [1]. The major problem with C now is the compiler writers trying to exploit undefined behavior to increase speed, to the point that formerly valid C code now breaks.

                                                                      [1] Byte addressable, 2’s-complement won. Get over it C Standards Committee!

                                                                      1. 1

                                                                        The major problem with C now is the compiler writers trying to exploit undefined behavior to increase speed, to the point that formerly valid C code now breaks.

                                                                        I think the major problem is people compiling with -O3 and then complaining that compilers are trying to make their broken code fast.

                                                                        1. 0

                                                                          The standard is full of contradictions and obscurities. Compiler writers treating the standard as if it were some shrink wrap contract that they could exploit to evade every obligation to their users is simply wrong. The code you complain is “broken” is not even broken according to the standard and is common in things like K&R2. It’s ridiculous to claim that exploiting loopholes in murky standard written by a committee that seems to have no idea what they are doing is somehow justifiable.

                                                                        2. 1

                                                                          You may get your wish soon. From https://herbsutter.com/2018/11/13/trip-report-fall-iso-c-standards-meeting-san-diego/:

                                                                          … all known modern computers are two’s complement machines, and, no, we don’t really care about using C++ (or C) on the ones that aren’t. The C standard is likely to adopt the same change.

                                                                          1. 0

                                                                            I think K&R2 is basically C at its best and that is ANSI. I even like restrict, although God knows the description of it in the standard reads like the authors were typing it on their phones while working at the Motor Vehicle Bureau. But there are programs in K&R2 that are not valid programs according to the current interpretation of the current incarnation of the standard.

                                                                    2. 3

                                                                      esides, the entire point of typedef is to guard against this sort of thing, though.

                                                                      The big flaw in typedef is that there is implicit type conversion between e.g. typedef int metric x and typedef int english y that permits x = y etc. There should be a flag in C to give warnings on all implicit type conversions. and a strong typedef (although the struct method works well too )

                                                                      1. 3

                                                                        To solve this thing, just do that thing!

                                                                        If it’s so simple and yet so easy to forget… why don’t we just automate it? 😉

                                                                        1. 0

                                                                          why don’t we just automate it?

                                                                          If you read what I have written, that is what I said. scan-build+sparse+cppcheck+valgrind will catch 99% of the errors mentioned in the article, and they take only about 5 seconds to run.

                                                                          1. 7

                                                                            Sounds to me like you’re choosing a language that requires boilerplate, then installing tools to scan for missing boilerplate.

                                                                            For something as important as memory safety, it seems shortsighted to arrive at such a solution. But to each their own: if a certain workflow helps you produce safe code, then I won’t complain it puts the cart before the horse.

                                                                            1. 3

                                                                              Valgrind requires you to exhaustively test your application. That’s not a five-second job.

                                                                          2. 1

                                                                            Nulling things only works if you have a single pointer to the memory, and pass that pointer by reference when you need it

                                                                          3. 10

                                                                            Unpopular opinion puffin meme time!

                                                                            I’ve seen this “move to memory safe languages will solve all our problems” argument too many times. There’s a few problems with it:

                                                                            1. The language itself must never use unsafe code and must never contain any type of vulnerabilities.
                                                                            2. The entire operating system must be rewritten in that language. Everything from the bootloader to the kernel to the entire userland (and that includes libc). This new operating system must contain the same feature parity, including the same KBI, KPI, ABI, and API as the old operating system.
                                                                            3. Just because memory safety is solved doesn’t mean that all types of vulnerabilities are solved as well. Think: LFI/RFI with PHP doesn’t involve memory safety vulnerabilities at all.
                                                                            4. All the legacy code deployed on legacy devices. Not only do you have to rewrite the operating system, but you have to replace the billions and billions of Internet-connected devices.
                                                                            5. Perhaps I’m forgetting something. Place whatever I’m forgetting here. ;)

                                                                            edit[0]: Add an item.

                                                                            1. 14

                                                                              (Samuel L. Jackson voice) “Oh you were finished? Well, allow me to retort.”

                                                                              1. This is already countered if goal is fewer vulnerabilities, which safe languages lead to. If aiming for all, safe languages are only a start. The unsafe must be verified using external tools that do exist. The other vulnerabilities will need to be mitigated by review, language extensions, libraries, and/or external tools. Good news is many of these exist and can be added to toolset. Also, eliminating entire classes of errors gives developers more time to focus on others.

                                                                              2. The OS does not need to be rewritten. First, you only need to mitigate the code you use. Projects like Poly2 literally remove every call and feature they dont need. Of the rest, you can use tools that make legacy C memory safe with a performance hit. Then, begin the rewrites on the fast paths to gradually reduce overall performance hit. The C safety scheme is dropped at the end.

                                                                              3. That’s true. I addressed it in No 1. Another example is web application attacks that memory safety doesnt mitigate. So, new language designs addressed more of those risks in form of Ur/Web, Opa, and JIF/SIF. Those can be ported to more popular, safe languages. Rinse repeat.

                                                                              4. The make-C-safer tools, C-to-other stuff, sound analyzers, and separation kernels address legacy. Partly. Legacy will always be a big problem. What you overlook with IoT devices is that’s easiest market to get new code into. About opposite of legacy.

                                                                              5. Ada getting better results than C effortlessly for decades. SPARK getting pointers. Why3 getting support for bit-level issues. Industrial adoption of these by some companies. Shit is getting extra real on prove it has no errors side of things. Slow but steady progress.

                                                                              1. 1

                                                                                Mostly agreed. Note that I’m not saying to not use memory safe languages. My problem is with those who claim that there is no use for C and that C should just die already.

                                                                                The reason why I said the OS would need to be rewritten is because parts of the runtime likely depend on libc (and possibly other C-based libraries (libpthread?)). Those libraries are written in memory unsafe languages, like C, and could be used in an attack.

                                                                              2. 5

                                                                                This is an understandable opinion. As one of the principal authors of Monte, a language that might be characterized as claiming that moving to capability-safe (and thus memory-safe) languages will solve many of our problems, I can at least explain what the world on the other side of the looking-glass looks like.

                                                                                1. Yes, we might hope. There are three pieces. The language should not have unsafe escape hatches, the trusted parts of its implementation should be correct (relative to some specification), and the language should exclude every known bug class. These are tall demands, but Monte does at least achieve the first of them. I think that the other two are moving targets, in that our understanding of bug classes is not always deep and axiomatically-preventable, as with buffer overflows or out-of-bounds access, but is sometimes not conceptually obvious, like misquotation/injection, or emerges from the marching-on of science and technology, like timing-related side-channel-driven data exfiltration, or can even be definitionally incomplete, like plan interference.
                                                                                2. Yes, eventually. Note that there is a benefit to doing this rewrite aside from the hoped-for permanent elimination of some bug classes, though; we don’t have to implement any of the old APIs. This is actually something we expect in the object-capability worldview, because of the phenomenon of taming. Old APIs usually are untamed, and by the time that they are tamed, they no longer are compatible. In the typical Monte module, one cannot open a file, connect with a socket, write to stdout, redefine builtin names, examine a caught exception, or set up module-private global mutable state. Sincere capability-first systems like Genode and seL4 have APIs that tend to seem alien to newcomers, deeply limiting what the typical userland process can do.
                                                                                3. Yes. This relates quite a bit to the first point. We can only claim that some specific bug classes are impossible as a consequence of the underlying structure of the language. For example, Monte does not have a memory model, and consequently some classes of memory bug are not possible. (Of course, to recall your first point in its entirety, bugs in the runtime are possible, and since we generally run on memory-unsafe CPUs, we should be prepared for bugs in the runtime to be exploitable from user code.)
                                                                                4. Yes, but it’s okay, because we already were using language-agnostic abstractions in many cases. As you point out, the Internet is a thing, and many computers are connected through it. But, at the same time, the Internet is not only accessible from memory-unsafe languages. Monte speaks JSON and HTTP just like other modern languages. Nobody is requesting that the ocean be boiled all in a day, merely that we consider the benefits of not drinking seawater.
                                                                                5. Your opinion is not at all unpopular. It is, in fact, the dominant opinion, and many conversations I’ve had with security professionals have consisted entirely of me trying to break through their memetic armor in order to have a conversation.
                                                                                1. 3

                                                                                  Sounds like a list of good ideas. Let’s do it!

                                                                                  1. -2

                                                                                    People often confuse architectural problems and competence problems with language problems. Most of the security bugs I’ve seen from C programs are due to (a)unskilled programmers and (b) failure to do simple things like use multiple memory protected processes. If program A parses inputs and sends data in parsed form to B, then a pointer exploit in A will not be able to control B - which is the process that should do privilege escalation. As for the first problem, nobody would complain that steel struts are poorly made if major bridges were being constructed by engineers who didn’t know how to calculate load.

                                                                                    People also tend to discount the single-failure point of memory failures in single address space programs. There is no difference in safety between code that is 100% written in despicable C and code that is 99.99% written in super virtuous Rust/Haskell/Pascal/Ada/Javascript/Snobol or whatever, if that 0.01% code is not memory safe.

                                                                                  2. 4

                                                                                    I think the bigger problem is that people extend the security expectations of tools and then get surprised that they weren’t designed with it in mind. ImageMagick is a great tool, but I assume it originally thought you’re manipulating your own images, not untrusted ones. People started expecting that and are surprised their needs are not magically met.

                                                                                    1. -1

                                                                                      Good point. Using security issues in ImageMagik as evidence of flaws in C is beyond stupid.

                                                                                    2. 4

                                                                                      And for those of us who use or want to use C/C++ for our Internet (specifically, web) systems, please let me know if https://learnbchs.org is helpful for tools and deployment strategies that aren’t limited to “use rust”. (Disclaimer: I wrote it.)

                                                                                      1. 2

                                                                                        Hi, yeah, personally I would be put off by that stack? OpenBSD is great and I’ve been meaning to deploying something with httpd for a minute now just to play with it, but using sqlite for a web app is a deal breaker and C as a web language…also a deal breaker. Just not what i would use personally, for a lot of different reasons. But thanks for the link and the site looks great.

                                                                                      2. 6

                                                                                        While it’s true that there are better languages to guarantee memory safety, I would argue it’s not a huge problem in terms of cost compared to other problems of the internet. I think the larger issue is energy cost of the internet. In fact likely most code running the web is NOT c/c++ and instead IS using memory safe languages.

                                                                                        The risk of climate change is so huge, and the costs so High (from 10 trillion to human extinction ) that security pales in comparison to the cost of global warming. I simply cannot justify sacrificing performance for security because of this. If using C/C++ can reduce your energy and server use, then it’s a superior choice over safety.

                                                                                        Rust is interesting here because it doesn’t sacrifice speed for safety. My biggest concern with it is that it’s just not as pleasant compared to c++. Maybe it will get better genetic programming in the future. But to me energy use is the elephant in the room.

                                                                                        1. 4

                                                                                          The use of slower languages also favors “cloud vendors” (people spend more on compute nodes if their code is slow). Those same vendors often promote slower languages. Conflicting priorities for sure.

                                                                                          1. 3

                                                                                            Would be interesting if someone actually tried to measure the impact of scripting language usage on the power consumption of servers around the world in general.

                                                                                            I guess it’s not that big. It’s mostly the small sites that are written in PHP/Python/Ruby/etc. The stuff serving most of the world’s traffic is very efficient. Netflix’s CDN uses in-kernel TLS crypto. Google Search is, I think, C++. Twitter famously migrated from Ruby to Scala and other JVM stuff. And so on.

                                                                                            1. 6

                                                                                              The problem is that most servers are on 24/7 and mostly idle. When people use slower languages, they tend to overprovision servers to handle load spikes. So instead of thinking about “efficiency per request” this about “machines per load”. If you can reduce the number of machines you use by 1/10th by using a faster language, that’s basically a 1/10th reduction in power. And it’s not ONLY a reduction in power but a huge reduction in physical waste.

                                                                                              I think I read somewhere that 90% of machines on the internet are sitting idle.

                                                                                              That’s why I love the idea of unikernels since they boot in miliseconds. If you can have a machine literally turn on and serve a request when a packet comes in, vs having it running idle, it could be a huge win for power. You simply can’t do that with a VM based language whichtypically has a cost to start the VM and requires a VM warmup to be fast.

                                                                                                1. 1

                                                                                                  Nice! Didn’t know the name of that, thanks.

                                                                                              1. 2

                                                                                                Stuff like that exists. Hard to Google on mobile cuz lots of crap results. I did find a result that at a glance looks like kind of stuff I was thinking off. Hows this?

                                                                                              2. 3

                                                                                                “In fact likely most code running the web is NOT c/c++ and instead IS using memory safe languages.”

                                                                                                Good point. The new ones are more efficient. That will help address this problem. Hardware people stay getting watts down. People really concerned should probably also use energy-optimized CPU’s like ARM makes for their systems with embedded or laptop peripherals since they’re low power. Such a rig wont have great performance per dollar ratio, though.

                                                                                                1. 2

                                                                                                  The ‘energy cost’ to create and maintain a working programmer is pretty substantial, too - to what degree does that dictate ‘use the language that lets you get the most out of that expenditure’?

                                                                                                  1. 2

                                                                                                    It’s a false dichotomy. C++ is a high level language and modern c++ is very productive. You can make code that almost looks like python but with huge performance over python.

                                                                                                    Secondly, energy is the main cost of a data center, so let’s tackle that first. It hasn’t been true for a long time that programmers cost more than the cost of running their software.

                                                                                                    Third, we can produce less software in general. Productivity is the greatest source of waste anyway.

                                                                                                    1. 9

                                                                                                      Third, we can produce less software in general.

                                                                                                      Heh. There would be a lot fewer bugs if we fixed the software we have instead of churning out new bugs. But good luck getting developers to admit that.

                                                                                                      1. 1

                                                                                                        My cookie file has the following quote:

                                                                                                        Every program has at least one bug and can be shortened by at least one instruction—from which, by induction, one can deduce that every program can be reduced to one instruction which doesn’t work.

                                                                                                        And before you dismiss that as silly, there was a one-instruction program that had a bug.

                                                                                                2. 3

                                                                                                  If you wanna convince me to join your side of the fence, come over to mine and walk me through the border. Screaming at me from the other side is only gonna repel me.

                                                                                                  The bigger issue with a huge subset of developers isn’t that they don’t prioritize security, but that they set their opinions in stone. Both sides of this debate rage on and on with mainly logical and compelling arguments, collecting more followers as they go, but the size of the intersection just keeps on shrinking.

                                                                                                  If you read something and think “This is very stupid”, I ask you to kindly take a break and ask yourself this question before pressing enter:

                                                                                                  what do I wanna achieve with my response?

                                                                                                  I’m emotionally attached to C, it was my first language. I’d like to think I know a lot about it. I definitely like programming in it. I acknowledge it has warts. I acknowledge some of them are really big. I know we can do better. I’m willing to change my mind.

                                                                                                  So dear stranger on the internet more knowing than I, can you show me you come from a point of reason, and that even you are willing to change your mind?

                                                                                                  1. 5

                                                                                                    I’m a programmer who’s written a decent amount of code in C and C++, although I wouldn’t call myself particularly emotionally attached to either. I’m a fan of Rust because it fixes a lot of C and C++’s warts, brings a lot of cool ideas from functional programming and other higher-level programming languages to a low-level systems context, and because I ideologically approve of the general project that Rust facilitates, namely statically-guaranteeing as much correct behavior out of your program as possible.

                                                                                                    Here’s something that you, as a C programmer, might want to try. In Rust you can write functions that conform to the C ABI fairly easily. This allows you to call C functions from Rust and call Rust functions from C, and you can compile Rust code to a library that can be linked into a C program, the same as any other library. The next time you want to add some functionality to an existing C project that you have, why not go to the trouble of setting up your build system so you can link a Rust library, write an extern "C" function in Rust that can be invoked from your existing C code, and then implement the feature in Rust? This will give you a chance to see how much you like working in Rust, and apart from making the build system a bit more complicated, won’t affect any existing C code.

                                                                                                    1. 1

                                                                                                      Thank you for your response, I’m currently in the process of designing a small embedded system, and I’ve been considering to give a Rust a try, but there\s currently no LLVM backend for the architecture (xtensa) we wanted to use. Though your suggestion gives me the chance to test Rust on some of our other C projects which run on better supported architectures.

                                                                                                    2. 1

                                                                                                      I’m emotionally attached to C

                                                                                                      I don’t understand this - the same way I don’t understand why someone would get emotionally attached to the company they work for.

                                                                                                      1. 1

                                                                                                        Emotional attachment as I think of it, can be positive or negative. In my case with C it’s positive, maybe you’re also emotionally attached to C, but negatively?

                                                                                                        Emotions control our behavior day in and day out, and I personally do not see them as a bad thing at all, as long one can honestly reflect on what emotions are influencing the decisions they make.

                                                                                                        As for people who get emotionally (positively) attached to their companies. I’ve never been in that camp, but I do very much understand why they would. Humans aren’t rational agents, humans are animals driven by the need to survive, belong, reproduce and so on. If your company is doing something you believe in, and your coworkers are actual friends, why shouldn’t you get emotionally attached to the company? and what’s there to question about that?

                                                                                                        I do hate company cults, but rarely do I have trouble understanding why it happens. Companies like any other group of people aren’t gonna magically take out the emotional human parts in us that do govern our everyday life.

                                                                                                        1. 1

                                                                                                          I’m not emotionally attached to C but I am to Perl 5. It’s partly because I’m pretty good at the language, and the switching costs would be pretty high, partly because I think most humans develop a certain attachment to tools and objects they use, despite there being alternatives that are objectively better.

                                                                                                          Now, if I were to be hired to work as a programmer (as opposed to generalist IT dude) and my employer said we’re gonna just Baz2018 instead of Foo99 from now on, of course I’d switch, and perhaps not miss Foo99 in the slightest.

                                                                                                      2. 2

                                                                                                        I was going to say “Isn’t Swift just a nicer syntax for Objective-C?”.

                                                                                                        Apple’s Swift programming language is also memory safe, while its predecessor, Objective-C, was not.

                                                                                                        TIL.

                                                                                                        1. 2

                                                                                                          So I saw this pop up, and was like “oh, I’ll go see what people are saying at lobsters” ….“hmmm, the author hasn’t submitted it yet here, I wonder why that is……”

                                                                                                          1. 2

                                                                                                            Nobody’s dealing with the problem because it’s a red herring to market other programming languages.

                                                                                                            Tools like Coverity and Valgrind can catch most buffer overflows, null pointer dereferences, int overflows, and similar problems. Those are standard tools along with the compiler and the debugger. People who don’t put in the effort to run them will write buggy code in any language because they’re being sloppy and lazy.

                                                                                                            And “safe” languages aren’t a panacea. Equifax lost millions of people’s data due to an unpatched Java framework (Struts). WordPress gets hacked left and right, and it’s written in PHP. Sloppy coding causes bugs in every language.

                                                                                                            So nobody’s rushing out to rewrite all of the C and C++ applications because the people with the skill to do so realize it’s really not going to solve many problems.

                                                                                                            1. 9

                                                                                                              Re sloppy programmers. Evidence is already in that giving them safe languages and libraries drastically reduces number of vulnerabilities that lead to code injection. That was the goal if perfect security couldnt be achieved.

                                                                                                              Re safety. It’s worth remembering that safety, like security, is always about specific properties (eg memory safety). We should keep the context in there. The Java language might be safe against specific memory issues but isn’t safe against web issues.

                                                                                                              1. 2

                                                                                                                Re safety. It’s worth remembering that safety, like security, is always about specific properties (eg memory safety). We should keep the context in there. The Java language might be safe against specific memory issues but isn’t safe against web issues.

                                                                                                                I guess that’s kind of what I was getting at. I’ve worked on several big (500k+ loc) projects, over the years, and have only seen a handful of buffer overflow and null pointer bugs slip into production. Not to say they aren’t there, but in the big picture they make up a relatively small portion of bugs.

                                                                                                                1. 2

                                                                                                                  I could see that. The other thing to distinguish is bugs that dead to attacker control of system vs leak some data vs low-damage effect like a crash. The C/C++ applications tend to have a lot on the left side vs alternatives. The exception is if it’s a safe language with heavyweight runtime that’s itself contains lots of unsafe code in C/C++. Java got trashed a lot due to this. That just further justifies C/C++ opponents’ position, though.

                                                                                                                  C/C++ can be better at preventing leaks due to direct control of memory. Whereas, safe, low-level languages can equal or surpass it depending on type system. Especially in information-flow tracking languages. Finally, some alternatives make crash handling and updates better but usually heavier stuff like Erlang. I have submitted designs for C or C++ (can’t recall which) that let it do things like checkpointing with a performance hit.

                                                                                                                  So, there’s definitely extra context to think about. That attacker control being an easy default on any C/C++ developers’ mistakes just makes it the worst default if safety or security are a concern. If productivity or debugging are a concern, then there’s still other stuff that’s better. Aside from personal pleasure, raw efficiency using specific, mature compilers on code that absolutely needs it is about only justification I can think of using it. And with every analyzer or test tool one can throw at it.

                                                                                                                  1. 0

                                                                                                                    I wouldn’t consider 500kSLOC to be big.

                                                                                                                2. 2

                                                                                                                  Tools like Coverity and Valgrind

                                                                                                                  One is proprietary, the other is dynamic, I believe. That is a big problem.

                                                                                                                  1. 1

                                                                                                                    It is unfortunate that the best static analysis tools are proprietary, but they’re not too expensive and IME companies don’t mind buying them. It’s widely considered a cost that goes along with writing C++. Some commercial services even offer to scan open source projects for free. And there are some open source alternatives, but they’re not quite as good.

                                                                                                                    It’s a weird oversight in the world of FOSS developer tools, but there’s some work being done to add the checks into clang and gcc.

                                                                                                                    1. 6

                                                                                                                      “More than 5500 open source projects and 27000 developers use Coverity Scan”

                                                                                                                      These numbers are incredibly low. I wonder why?

                                                                                                                      How much is it anyway? No pricing on the site. Of course. I find an old HN post claiming it starts well into five figures. That’s kind of a big deal for many small companies as well as not-so-small companies whose primary line of business isn’t software.

                                                                                                                3. 2

                                                                                                                  I think the problem is something else entirely. The field of computer science has a problem with trying to define away hard problems. C/C++ are hugely succesful languages for good reasons. Making better languages or, more usefully, improving code analyzers for C, writing better C code, these things are hard. Declaring that C/C++ suck and that there is a magic cure is a lot easier.

                                                                                                                  1. 8

                                                                                                                    Although I agree with tool development and use being high priority, I think your last point about C/C++ suckage is off since we can prove it does for verifiable software. Just gotta look at effort vs what’s gained.

                                                                                                                    1. Pascal-, ML-, and LISP-like languages. Early work on formal semantics for verification was done on these with fairly quick results. They got some use out of them with 1970’s-1980’s era methods. It was also easiest to certify the code generators and such. SPARK generated the most ROI. The common denominator was they were designed in a way to make formalization easier and verification feasible.

                                                                                                                    2. BCPL was what random features compiled on a terrible computer. It was tweaked and extended in ad hoc way with strong limitations and dependencies imposed by a less terrible computer. It was extended with no verification in mind for years. The result was a language so hard to formalize that CompSci folks needed 40 years of advancements in provers and hardware to do simple, Pascal-like subsets. Another 10-20 years before realistic semantics appear… maybe 2 or 3 of them. Those are either subsets or leave off compiler extensions.

                                                                                                                    The comparison indicates that, compared to alternatives (esp Gypsy or SPARK), C was and still is ridiculously hard to formalize for safety analysis since it was (a) not designed for verification and (b) has significant, incidental complexity tied to its ad-hoc development on PDP-11. It does suck for anyone wanting to be certain code is ssfe with minimal work. Even more for folks building those tools.

                                                                                                                    1. 0

                                                                                                                      I don’t believe anyone knows how to do verification, so nobody knows how to make verification easier. I’m super skeptical about it being easier to build a mathematical model of ADA than KR-C (as opposed to the so-called C-standard C, otherwise known as Botched Pascal)

                                                                                                                      1. 2

                                                                                                                        Nah, they built models of Pascal-like languages most of the time. One generated Ada. SPARK was a subset of Ada they could handle plus verification-related extensions.

                                                                                                                    2. 7

                                                                                                                      What’s wrong with putting the work in, making a better language (arguable), then declaring it a cure?

                                                                                                                      1. 2

                                                                                                                        C/C++ are hugely succesful languages for good reasons

                                                                                                                        Yes.

                                                                                                                        C, because it was the systems language of Unix, and that ended up getting popular.

                                                                                                                        C++, because of its near perfect backwards compatibility with C while making it better.

                                                                                                                        writing better C code, these things are hard

                                                                                                                        So hard that basically nobody manages.

                                                                                                                        Declaring that C/C++ suck

                                                                                                                        Compared to alternatives.

                                                                                                                        there is a magic cure is a lot easier

                                                                                                                        I don’t think anyone is saying there’s a magic cure. Only that there are better ways of writing software than the current ones that would eliminate an entire class of bugs.

                                                                                                                      2. 2

                                                                                                                        Others have hit on this problem, but I’ll make it a top-level comment: who is going to pay for this? I am pretty decent at Rust. I love working on infrastructure. I’m a senior engineer by most org charts. I’ve never seen any sort of job opportunity for this.

                                                                                                                        Tech’s biggest problem is too much money being involved.

                                                                                                                        1. 3

                                                                                                                          It’s more strange that there’s a tremendous amount of money involved, but very little of it ever seems to make its way towards maintaining and improving core system and applications. It all ends up going towards showing us more ads, and figuring out how to gather more of our personal information, so that companies can show us more ads.

                                                                                                                          1. 2

                                                                                                                            Tech’s biggest problem is too much money being involved.

                                                                                                                            Or not enough money, depending on how you look at it. When security is opt in, the market will opt out to save a buck.

                                                                                                                            1. 1

                                                                                                                              I seem to be working professionally on an infrastructure project in Rust. We got there because we needed to build a bare-metal version and I insisted on Rust. Near as I can tell, there are more than a few other companies doing infrastructure work in Rust. It’s still far from the majority, but this is to be expected from a language that’s only been stable for ~3 years.

                                                                                                                              1. 1

                                                                                                                                Looks like a great application for Rust! Best wishes to your project.