Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Programming Bug Security

TechCrunch Urges Developers: Replace C Code With Rust (techcrunch.com) 505

Software engineer and TechCrunch columnist Jon Evans writes that the C programming language "gives its users far too much artillery with which to shoot their feet off" and is "no longer suitable for the world which C has built." An anonymous reader shared Evans' post: Copious experience has taught us all, the hard way, that it is very difficult, verging on "basically impossible," to write extensive amounts of C code that is not riddled with security holes. As I wrote two years ago, in my first Death To C piece... "Buffer overflows and dangling pointers lead to catastrophic security holes, again and again and again, just like yesteryear, just like all the years of yore. We cannot afford its gargantuan, gaping security blind spots any more. It's long past time to retire and replace it with another language.

"The trouble is, most modern languages don't even try to replace C... They're not good at the thing C does best: getting down to the bare metal and working at mach speed." Today I am seriously suggesting that when engineers refactor existing C code, especially parsers and other input handlers, they replace it -- slowly, bit by bit -- with Rust... we are only going to dig ourselves out of our giant collective security hole iteratively, one shovelful of better code and better tooling at a time."

He also suggests other fixes -- like using a language-theoretic approach which conceptualizes valid inputs as their own formal language, and formal verification of the correctness of algorithms. But he still insists that "C has become a monster" -- and that we must start replacing it with Rust.
This discussion has been archived. No new comments can be posted.

TechCrunch Urges Developers: Replace C Code With Rust

Comments Filter:
  • Yes, go ahead! (Score:5, Insightful)

    by mveloso ( 325617 ) on Sunday July 16, 2017 @01:20PM (#54820189)

    Yes, replace billions of working C code with billions of lines of code in a new language. What could possibly go wrong?

    • by SCVonSteroids ( 2816091 ) on Sunday July 16, 2017 @01:30PM (#54820241)

      Well if this guy says so, what doubts could you possibly have left?

      • by doom ( 14564 )

        It's pretty impressive for a pundit to come up with this idea. Of course, "let's rewrite everything in rust!" it's already such a cliche I've seen people moderated down for posting it, but you have to expect pundits to be a little slow on these things.

        The response of the postgresql folks was something like "how about we finish porting it from lisp, first?"

    • Re:Yes, go ahead! (Score:5, Insightful)

      by BCooley ( 899054 ) on Sunday July 16, 2017 @01:37PM (#54820281)

      He's not suggesting that at all.

      "..I am seriously suggesting that when engineers refactor existing C code, especially parsers and other input handlers, they replace it — slowly, bit by bit — with Rust."

      He's suggesting that when you refactor a critical piece of C code - in other words you're already going to change it and potentially add brand new C/C++ security issues - you instead use a language with some form of god damn formal verification and some fucking way of validating that you're not opening a new exploitable vulnerability that will bring down half the damn internet.

      I mean is that really too much to ask?

      • Re:Yes, go ahead! (Score:5, Interesting)

        by Chris Mattern ( 191822 ) on Sunday July 16, 2017 @01:53PM (#54820373)

        I mean is that really too much to ask?

        Yes. Formal verification of most production programs will not happen in my lifetime or yours, or possibly ever, because it's expensive and nobody's paying for it.

        The simple fact is that there's a hue and cry about security but nobody really cares about it, because nobody's willing and able to pay what it would take to fix it.

        • by plopez ( 54068 )

          What needs to happen is the cost of security breaches must greatly exceed the cost to fix it. The only way I can see that happening is huge fines and/or civil accountability. In other words government fixing the market place.

          • Re:Yes, go ahead! (Score:5, Insightful)

            by ShanghaiBill ( 739463 ) on Sunday July 16, 2017 @03:06PM (#54820837)

            What needs to happen is the cost of security breaches must greatly exceed the cost

            Why does that "need" to happen? If there was actually a "need" for secure and expensive software the marketplace would already be providing it. Most people want cheap, or even better, free. There is no political demand for an authoritarian solution to online security, nor should there be. Government involvement will stifle innovation, increase costs, and do little to actually solve the problem.

        • Re:Yes, go ahead! (Score:5, Insightful)

          by Jeremi ( 14640 ) on Sunday July 16, 2017 @03:10PM (#54820847) Homepage

          Yes. Formal verification of most production programs will not happen in my lifetime or yours, or possibly ever, because it's expensive and nobody's paying for it.

          The idea with Rust is that the Rust compiler does a significant amount of formal verification so that human beings don't have to.

          It won't guarantee that your program does what you intended, but at least if your Rust program compiles, you have a pretty good assurance that it won't be corrupting its memory space and suffering from (potentially-exploitable) Undefined Behavior when it runs.

          The simple fact is that there's a hue and cry about security but nobody really cares about it, because nobody's willing and able to pay what it would take to fix it.

          There's some truth to that; in most cases, people are only going to invest a modest, finite amount of additional time/effort/money into making code secure.

          Which is why it makes sense to minimize the cost of making code secure, e.g. by building the necessary checks into the language itself so that all programs benefit from them "for free".

          • Re:Yes, go ahead! (Score:5, Insightful)

            by TheRaven64 ( 641858 ) on Monday July 17, 2017 @05:27AM (#54824105) Journal

            The idea with Rust is that the Rust compiler does a significant amount of formal verification so that human beings don't have to.

            Please don't confuse type checking, using a non-verified type system, with formal verification.

    • Yes, replace billions of working C code with billions of lines of code in a new language. What could possibly go wrong?

      Not only that, but which standard requires that a system have a rust compiler on it? POSIX and SUS (are they the same now?) require a C compiler. In practice I know that many systems have other environments available, but standards matter in some cases and there will be instances where C is an appropriate choice, if not the best or only choice.

      I could understand advocating "choose rust instead of C for new projects" or "if you are considering rewriting major portions of a C project then con

    • by Anonymous Coward on Sunday July 16, 2017 @01:55PM (#54820381)

      The Rust community really worries me. It's far too tyrannical for my tastes. For example, they apparently aren't capable of acting like civilized adults on their own. They need a Code of Conduct to tell them how to behave, and a Moderation Team to act as what is effectively a judge/jury/executioner role.

      What's worse is when they use these tyrannical apparatuses to attack others. For all of their bragging about how they value "tolerance" and "inclusivity", they so often exhibit the opposite behaviors. Just look at any Reddit or Hacker News discussion about Rust. Anyone who doesn't post a glowingly positive comment about Rust will quickly become the victim of downvote attacks. It worries me when people offering valid, correct and relevant criticisms of a technology are attacked, censored and silenced.

      I've used a lot of languages over the years, from C to C++ to Java to Perl to PHP to Erlang to Haskell. But none of them have had communities as hypocritical, contradictory and tyrannical as I have found Rust's to be.

    • Re:Yes, go ahead! (Score:5, Insightful)

      by jmccue ( 834797 ) on Sunday July 16, 2017 @01:58PM (#54820407) Homepage

      I think we should replace c with COBOL, no pointers, no dynamic memory allocation, rounding errors with floats rare and all strings fixed length.

      That is just as good an option as any for these crazy "my language is better than your's" posts

    • by Anonymous Coward on Sunday July 16, 2017 @02:09PM (#54820463)

      Rust is very tied to Mozilla. And Mozilla's only remaining "successful" product is Firefox. But Firefox's market share is dropping. It was only a few percent, last I saw, while Chrome is over 50%. Mozilla reportedly gets a lot of funding from Yahoo, due to a Firefox search deal. So here we have an organization with one major product, but this project is being rejected by consumers, and what might be this organization's most significant source of revenue comes from this failing product and is paid for by another company that isn't doing so well. I fear for Mozilla's future if, say, the Yahoo deal wasn't renewed and they couldn't find a replacement.

      If Mozilla goes the way of the dodo bird, then I can't see the Rust project really going anywhere. I don't think it has a robust independent community like Python or C++ has, for example.

      I think it is too risky to adopt Rust, especially for important long term projects. The tech industry moves fast. Rust could plausibly be gone in 3 years, while languages like C, C++, Python and PHP are far more likely to be going strong.

      • by AaronW ( 33736 ) on Sunday July 16, 2017 @08:12PM (#54822421) Homepage

        I agree. If Firefox or Thunderbird is anything to go by I'd stay far away. I used Thunderbird for years until very recently but its performance is unusably bad. On my quad core xeon workstation it's almost impossible to write email because the editor freezes so frequently, often for seconds at a time. In the process it drops characters so I can't even type ahead. I suspect it's due to its single threaded nature and I'm dealing with several IMAP accounts with a LOT of emails. I recently switched over to KMail which seems to work far more smoothly. On top of that, Thunderbird is a huge memory pig. I gave up on Firefox ages ago and switched to Chrome due to horrible performance with single-threaded Javascript and the fact that it leaked memory like crazy for years. I also blame Mozilla for killing off MNG which is why we so often are STILL stuck with gif, which is a horrible format for most of the animations I see.

        Rust has its place but it isn't going to replace C any time soon. There are other languages that also make the same claims, i.e. Go, Swift, D, etc.

        One thing about C is it is supported on virtually everything except the micros where only assembly or some oddball language is the only thing supported (I used a processor that ran a pattern matching functional programming language at the hardware level once). There are plenty of other languages that are better than C in many cases, but one thing with C is you don't need to worry about libraries having weird interactions with other languages. C bindings are ubiquitous and very well understood and supported. C++ apps can easily link to and call C libraries but the other direction often requires some glue logic. Most languages can link against C code whereas the opposite is often not true. C has very minimal underlying requirements. I have written numerous bootloaders in C which require only around a page (or less) of assembly code. By boot loader, I'm talking about with no BIOS underneath for embedded systems. Cross compiling is well supported as well and I frequently am cross compiling for MIPS or AARCH64 with compilers that are tuned to the specific chips they're targeting.

        I'm playing with an ESP32 device right now which has two Xtensia cores in it. No Rust support but C and C++ are both supported. There's no underlying operating system. Similarly, one doesn't run Rust on Arduino platforms. Rust is tied almost exclusively to LLVM. There is no GCC support for Rust so there are plenty of platforms where Rust just isn't supported.

        C and C++ are supported by many toolchains, both open source and proprietary. Rust is not.

        • It's worth watching how Firefox goes as they begin to switch to Rust. If they see performance problems, or if their security bugs all go away (they won't, but you know, some of them might), then those are good data points.
    • Re:Yes, go ahead! (Score:5, Interesting)

      by Megane ( 129182 ) on Sunday July 16, 2017 @05:32PM (#54821663) Homepage
      How about this: rewrite systemd in Rust first and I might consider it.
  • Ada (Score:4, Interesting)

    by Anonymous Coward on Sunday July 16, 2017 @01:25PM (#54820201)

    Why now? Why rust? What about Ada? They're not so different that somehow the argument becomes that much better than it was for Ada. I just don't get all this rust hype. But, then again, I'm a C programmer, and I am 100% certainly I won't see C replaced in the systems I work on (cars), so it's a moot point. I would, however, support a move to Ada. My industry would never consider Rust. Pushing it over Ada is actually counterproduction, because it primes the C-suite to see languages pushed as a replacement for C as immature. Rust is still immature, way too immature for a conservative industry. Ada, though... maybe not.

    • Re:Ada (Score:5, Interesting)

      by david.emery ( 127135 ) on Sunday July 16, 2017 @01:45PM (#54820317)

      In part it's a cultural thing. Ada is considered "complex and verbose" (but compare with Java). Ada is, of course, from the DoD, so it's "obviously bad." Most importantly, Ada requires a bit more thought before you jump into the code.

      The interesting thing about Ada is that a skilled practitioner learns how to use the language to his advantage. You code so the compiler checks as much as it can, so you can concentrate on things the compiler can't check. When the compiler and you agree the code is correct, it probably is, at least with respect to typos and coding errors.

      One big criticism I have with most languages, even those with a type system, is they don't support strongly typed scalars. But that's where type errors are most common. I don't think I ever tried to "add apples to oranges". But I have tried to add "count of apples" to "count of oranges" (or more specifically, once tried to add horizontal pixel location to vertical pixel location.)

      Furthermore, those who think their C code is "close to the machine" don't know much about modern machine architectures. Compilers do a LOT MORE work than they did in the days of the PDP-8/PDP-11 or original x86 family. Ada (among other 'higher level' languages) provides the modern compiler with a lot more information for code selection and optimization. For example, register flushing is a lot easier to manage in Ada because pointer types are always declared as such, and unless there are specific language constructs, the compiler can prove a given variable will not be accessed through its address (and therefore doesn't have to spill the register to memory.) That's a simple example, compiler optimizations and instruction scheduling are very complex topics.

      Finally, I've always thought C syntax was harmful, because it's so easy to make a mistake, either through ignorance or simple typo ("=" vs "==").

      I know experts can do amazing things in C. Aren't that may experts out there slinging code, and most of the software we use these days shows it!!

      • Re: (Score:2, Interesting)

        by sphealey ( 2855 )

        Two other issues:
        1) having lost the race, there is no longer a viable ecosystem of Ada compilers, tools, etc outside of a few specialized (and very expensive) aerospace and DoD environments. That creates a large chicken-and-egg barrier to its use
        2) Back in the day Dijkstra strapped on the 10 most powerful swords and warhammers in human mythology and went after Ada full force. At the time his criticisms seemed on point, but with knowledge of what came after (e.g. Java) his obj

        • #1 is not true. See https://sourceforge.net/projec... [sourceforge.net] There's been a GPL Ada compiler for at least 30 years. The Ada Core product is open source, you pay for maintenance.

          For #2, the debate in many respects boils down to "simple programs in complex language" or "complex programs in a simple language." But see http://www.adacore.com/sparkpr... [adacore.com] (and there are free versions of that, too), for a subset of Ada specifically designed to support proof-of-correctness.

        • ...there is no longer a viable ecosystem of Ada compilers, tools, etc outside of a few specialized (and very expensive) aerospace and DoD environments.

          Say what? I've got gcc-ada installed on the system I'm using to post this.

          • by sphealey ( 2855 )

            That's one. How many industrial-quality C compilers are on the market and what is their price range?

            • I don't know how many industrial-strength C compilers there are. There are not many industrial-strength Ada compilers because there's not much demand, but there are a few [adahome.com]. The main project I've worked on involving Ada for a mission-critical application used AdaCore's GNAT PRO (they'd switched from another compiler - I don't know which one - and found GNAT PRO's built-in static checking to be far superior). AdaCore is cagey about pricing, though. I have a Janus Ada [rrsoftware.com] installation set somewhere; that's from US$

              • by sphealey ( 2855 )

                = = = here are not many industrial-strength Ada compilers because there's not much demand, but there are a few [adahome.com]. = = =

                Which is what I said ;-)

                = = = AdaCore is cagey about pricing, though. = = =

                Always how it is in the aerospace and DoD worlds!

      • How does Ada prevent buffer overflows?
        How does Ada prevent memory leaks?

        (Maybe I should also ask how Ada prevents rockets from exploding [wikipedia.org], but Rust won't do that either)
        • 1. No address arithmetic. Arrays are programmed with bounds-checking, usually through dope vectors generated by the compiler. It is a requirement of the language to generate an exception if you try to go beyond the bounds of the array.

          2. Ada handles pointers through access types (which, by the way, are always checked before dereferencing to be sure the pointer is not null). There are coding styles and means to do memory management, e.g. setting up a memory pool for a specific access type. Ada95 and be

          • Arrays are programmed with bounds-checking, usually through dope vectors generated by the compiler. It is a requirement of the language to generate an exception if you try to go beyond the bounds of the array.

            Doesn't a bounds-check on every array access slow things down?

            • 1. It's maybe 1 instruction on most architectures.
              2. If you want security, you have to pay for it.
              3. In many cases, the compiler can prove the bounds check is not needed!
              Consider
              for index in some_array'range loop
              ... some_array(index) ....
              end loop;
              Unless you modify index (as an "l-value"), the compiler knows the values for index are exactly the bounds of the array (because 'range returns the range of values for the object some_index), so no bounds check is req

            • Doesn't a bounds-check on every array access slow things down?

              Not much. Ada is quite capable of hard-real-time applications (in some cases it's an advantage for those applications because the B&D nature of the language makes it more straightforward to write programs with a bounded maximum execution time, which can be more valuable than knowing something is usually a bit faster). And most compilers will let you switch it off, which might be sensible if you've proved out-of-range access to be impossible. Of course, if you're determined you can write crummy code and

        • Buffer overflows are a uniquely C (and assembler) thing. Most programming languages do actually do bounds checking, and will generate a run time error if you attempt to write more data to an array/block/other fixed size container than will fit. Ada is a normal programming language in this respect.

          Addressing memory leaks is a more complex subject, but you can reduce memory leaks if your programming language is built properly. You can't eliminate them, because it's always possible for a programmer to keep

          • Most programming languages do actually do bounds checking, and will generate a run time error if you attempt to write more data to an array/block/other fixed size container than will fit.

            Most programming languages are slower as a result of this bounds checking at runtime.

    • What about Ada?

      I came to this story to post this very question.

    • Re:Ada (Score:5, Interesting)

      by Rockoon ( 1252108 ) on Sunday July 16, 2017 @02:03PM (#54820439)
      This will come up again and again. Every generation will need to be taught about Ada.

      This guys beginning premise is wrong. People dont use C because its "getting down to the bare metal and working at mach speed." C is not a "bare metal language" so that cannot be the reason. The reasons that people use C mainly stem from it being based on a simple yet expressive-enough abstract machine.

      C isnt the ideal language for its purpose. The issue is really that none of the other languages are suitable upgrades. Many of those other languages can greatly help with "security" .. truly they can .. but they are not based on a "simple yet expressive-enough abstract machine."

      Now Ada as used in practice is the language if you are looking for formal proofs about the algorithms expressed. Not only does the Ada abstract machine lend itself to formal proofs, there is a whole mature ecosystem of analysis software for Ada already there and being used. Quite a bit of military contract stuff has to be done in Ada.
    • I won't see C replaced in the systems I work on (cars),

      C isn't being replaced but it also isn't being written.

      Simulink Embedded Coder / "Model Based Design" is taking over most industries.

      It's trivial to switch between C/C++. Adding Rust, ADA, etc shouldn't be too much of a leap.

      Rule of Generation

      • Developers should avoid writing code by hand and instead write abstract high-level programs that generate code. This rule aims to reduce human errors and save time.
    • by Hentes ( 2461350 )

      The first big problem with Ada is that its developers looked at the Pascal syntax and decided it would be a good challenge to make it even worse. In Ada variable, a pointer dereference (of any level) and a nullary function call look exactly the same. The second problem is that key language features have never been standardised. Some compilers support garbage collection, while in others you have to manage memory allocation by hand, which can easily leave you wondering why your code have suddenly started leak

  • I can't see CPython being replaced by RustPython anytime soon.
  • = = = Today I am seriously suggesting that when engineers refactor existing C code, especially parsers and other input handlers, they replace it -- slowly, bit by bit -- with Rust. = = =

    Or Erlang. Or Ada. Or PL/I. Or... or any of the 23 languages/environments that have been proposed since the Ada/Pascal/C split circa 1975. Yet none of these proposals have taken root. Why not? Seems to me that is just as important a research question as developing Yet Another Correct Compiler for the Unbreakable

  • by BarbaraHudson ( 3785311 ) <barbarahudsonNO@SPAMgmail.com> on Sunday July 16, 2017 @01:29PM (#54820231) Journal

    Basically, this is an admission that the average programmer is fairly shitty. Then again, you don't want average programmers working on anything important, so by sticking with c, you're not going to get the "rust, rust, baby" programmers.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      While in grad school I had a roommate take an introductory to programming course. I saw grave errors in the example code the lecturer was giving the students. It starts with the education. If they are not taught properly from the beginning don't expect anything but crap later.

      In the basic read stuff from a file example given to the students -

      char c;
      while ( (c=getc)!=-1) {
      }

      • Any smart teacher will slip in a mistake once in a while to see if anyone is paying attention. Then again, I'm not saying all, or even a majority, are smart.

    • by BCooley ( 899054 ) on Sunday July 16, 2017 @01:45PM (#54820325)

      Yeah.. expert C programmers never write insecure code.

      Except for when they do, which is pretty much constantly because true expert C programmers know it's impossible to write any large piece of C/C++ software using it's native features without making at least a few mistakes.

      If you're a C programmer, and you don't already know this, then you aren't an expert.

  • by lorinc ( 2470890 ) on Sunday July 16, 2017 @01:31PM (#54820245) Homepage Journal

    Hire competent C developers and you should be good to go. Hire dumb-asses and sure the future doesn't look bright.

    The usual PR stunt of "use my new language that is so good and so simple even a stupid high school teen with an IQ somewhere between stone and plankton in the phylogenetic tree could use it without wrecking anything" is not going to convince anybody here. It's boring at best, and no-one cares about your "advice".

    The linux kernel is in its 3rd decade, as most gnu/bsd tools and all of that is written in plain C. They are good and safe. Oh, maybe it's because they are written by competent guys.

    • I'd argue that there aren't many good reasons to favour C over C++ these days and there's a much simpler migration path as most C code is valid (though not idiomatic) C++ code. Replacing bare arrays with std::array, collections implemented in macros with ones implemented in templates, and raw pointers with std::unique_ptr / std::shared_ptr will go a long way to catching bugs. You retain the ability to easily sidestep the type system if you need to, but a lot of the things that require you to in C can be s
    • by Yosho ( 135835 )

      The linux kernel is in its 3rd decade, as most gnu/bsd tools and all of that is written in plain C. They are good and safe.

      Really? Are you sure [cvedetails.com]?

      • The first four bugs there wouldn't have been prevented by rewriting in Rust. They're logic errors (which happen in every language). That is the biggest downside or Rust: people think they will be secure by using it, leading to turning off their security brain.
    • Re: (Score:2, Flamebait)

      by Kohath ( 38547 )

      This is a common argument. What you're really saying is that a small number of elite developers feeling good about themselves is better than good tools that prevent mistakes.

      And the response is "No, it's not." We need more people to be able to produce more with fewer mistakes. The number of developers who write production code will always be more than the number of developers who write mistake-free code. The way to get more mistake-free code is to eliminate opportunities to make mistakes.

      Shorter version:

    • by sphealey ( 2855 )

      = = = Hire competent C developers and you should be good to go. Hire dumb-asses and sure the future doesn't look bright. = = =

      I've met a lot of very competent cabinetmakers over the years, but of those who use circular saws 80% are missing at least the tip of one finger. The SawStop technology seems like a good idea to me, although many deride it as "sissy stuff".

      In any case, the history of the last 30 years shows that you really can't depend only on having hired the "competent" programmers - there aren'

    • by gweihir ( 88907 )

      And that is exactly it. Sure, C is not that great a language, but it is simple, easy to understand in full (if you have what it takes) and it does not stand in your way. It also does not eat your cycles, unlike many, "modern" languages, but gives you native speed for what you are doing. As such, it works pretty well for anybody really competent. Insecure C code is not a language issue, it is a coder issue.

    • by Jeremi ( 14640 ) on Sunday July 16, 2017 @03:29PM (#54820947) Homepage

      Hire competent C developers and you should be good to go. Hire dumb-asses and sure the future doesn't look bright.

      A competent C developer will make only a very small number of mistakes per N lines of code, so that's a good thing.

      Of course, it only takes a single tiny mistake to produce potentially devastating consequences, so unless every single one of your C developers is not just good, but infallible, then by hiring "only" competent C programmers you are guaranteeing that your software will include a security hole, sooner or later.

      The problem with infallible C programmers is that they do not exist. The problem with competent C programmers is that there are only a limited number of them around, and it's not always easy to tell up front the competent C programmers from the seemingly-competent ones. Not to mention that every competent C programmer started out as a less-than-competent C programmer; if companies hired only competent C programmers, there would not be any competent C programmers since nobody would be able to make a living as a C programmer during the first N years of their programming career.

      Since the whole point of computers is to automate processes to make them quicker, easier, and less susceptible to human error, why would you not want to automate the creation of secure software, to the extent it is practical to do so?

      The linux kernel is in its 3rd decade, as most gnu/bsd tools and all of that is written in plain C. They are good and safe.

      Why do you think the Linux kernel is good and safe? It has suffered from many security holes [cvedetails.com] in the past, and will probably suffer from more in the future. There are almost certainly multiple gaping security holes in the Linux kernel right now, just waiting to be discovered and exploited. And this is despite it being written by competent guys.

      Imagine how much more robust the Linux kernel would be if the competent guys were also using a language that caught more of their mistakes at compile-time, rather than leaving them to be discovered by testers, users or hackers at some later date. Dunno if Rust is the language to do that, but it's hard to see how automatic coding-error detection wouldn't be a big improvement over the status quo.

    • Hire competent C developers and you should be good to go.

      Anyone who is a competent C programmer understands the limitations of the language, knows there's a lot of truth in his criticisms, and uses C only when there are no other reasonable options. They understand that because they're competent C programmers.

      You can write correct code in any language, or incorrect code in any language, but the choice of language makes a really big difference in how many errors your code has. C is a minefield of potential errors that don't exist in many other languages, and then

  • by Anonymous Coward on Sunday July 16, 2017 @01:35PM (#54820263)

    C was one of the most influential languages the world has ever seen, but all things reach a point where time moves and and they are not good ideas for new projects any more. I don't think we should necessarily go replace every line of C code out there - couldn't if we wnanted to - but for new projects we should use better tools now.

    Tools do matter. It's just way way way too easy to write buffer overflows in C, even for highly experienced programmers. History shows that clearly. We need better tools that are not so dependent on the human being doing the checking. That isn't to argue you can't write bugs in Rust, just that it helps the programmer avoid some classes of problems. Slashdot readers tend to think "if it isn't 100% perfect and can't guarantee bug-free code then it must be worthless", but that's autism thinking at its finest.

    People get attached to "the way things have always been done", but sometimes it really is best to move on. Yes, there is still COBOL code out in the world but that's not a language people use very often now for new projects. It did its job decades ago but we have learned lessons since then and we don't have to repeat the mistakes of the past.

    It's time to leave C in the past.

    • Re: (Score:3, Interesting)

      by TheRaven64 ( 641858 )

      It's just way way way too easy to write buffer overflows in C

      Technically: it's too easy to write buffer overflows in most implementations of C. The C specification makes accessing beyond the end of a buffer undefined behaviour. That means that an implementation is allowed to do whatever it wants (and doesn't have to do the same thing consistently). Most implementations implement this as 'trample an arbitrary memory location', but it's completely valid to transform it into a recoverable trap. My research group has proposed a small set of CPU extensions that we're

  • by gordona ( 121157 ) on Sunday July 16, 2017 @01:42PM (#54820305) Homepage
    How about training developers on security policy, training mgmt on the need for secure code and the balance between acceptible risk and convenience, proper requirement and tests.
  • If something needs to be done in C because it talks to hardware (and everything operation that computes eventually talks to hardware), then having another layer in front of it that still needs to talk to C code doesn't necessarily get rid your chance to make mistakes; it might in fact leave you even more rope to hang yourself with. And it won't look like the same kinds of errors you're making now, which is why you don't foresee it.

    One is data structures: in C there are no data structures. Any memory can be
  • "Did you build it right?" is easy to answer. "Did you build the right thing?" is not. Language choice has nothing to do with that.
    • by gweihir ( 88907 )

      Formal verification has failed. It is one of many coding hypes that has. "There is no silver bullet" still applies and it does not look like it will go away, possibly not ever. Sure, formal verification has some niche uses and it is a nice tool to teach code semantics, but that is it.

  • by CustomSolvers2 ( 4118921 ) on Sunday July 16, 2017 @01:53PM (#54820377) Homepage
    I have recently started a quite demanding development by fully relying on C and this experience has being quite eye-opening. One thing is knowing that C is really fast (and dangerous), but a completely different story is getting in there from a modern-language background.

    C can certainly be extremely problematic in bad hands (increasingly careless attitudes in the programming world, anyone?). Also I don't see the point of using it other than under very specific conditions. But completely replacing it? I don't think that this is neither possible nor logical.
    • by gweihir ( 88907 )

      Indeed. Use C for core algorithms, containers with tight space requirements, hardware access, etc. Use something modern for glue code, "business logic", UI, etc. like Python.

      The problem here is not C, it is incompetent C coders. I actually thing using C is an advantage, because it makes incompetent coders far more obvious than, for example, Java, were even the most incompetent ones can hack something together. The second problem is however incompetent "managers" that do not fire incompetent C coders, becaus

  • Security is the job of the Operating System, not applications, or users. When you run the program, and tell the OS which files it should use, that should be it. The program shouldn't have the authority to access anything not specified. This has worked in the mainframe world for decades, as you specified which virtual disks a system had access to when loading the run-time system. This works in virtualization, when you specify the disks the virtual machine is to use.

    It's going to be a few more years for th

    • by gtall ( 79522 )

      Yes, this. Now let's all trust MS Winders.

    • by gweihir ( 88907 )

      And then there are the cases where programs can access things and the security requirement is that they must not misuse them. Which is pretty much the most important case these days and most of it cannot be solved by MAC. You miss about 90% of the problem with your statement.

  • That will go well. Especially as Rust is nowhere near the "silver bullet" it is claimed to be. No. Just no.

    The actual fix is to hire competent coders. Incompetent ones will make their code just as insecure in Rust as they do in C. Sure, the insecurities will be different ones, but that is it. Software quality never has been a question of the language used. The only influence the language used has is how long coding takes. Software quality (and in particular security) is solely a question of the skills of th

  • by Alain Williams ( 2972 ) <addw@phcomp.co.uk> on Sunday July 16, 2017 @02:20PM (#54820539) Homepage

    To be able to code effectively in C you need to have been doing so for at least 3 years and, preferably, spent 6 months or more writing in assembler. I am not saying that without this people cannot write good C, but I believe that this is what is needed to provide you with the level of insight that is necessary to be a competent C programmer. To be a great one, add a few years experience.

    C is not a language for every one, it is not a language for all problems. But for some it is a good language. The trouble is that some people use it when the, perhaps, should be using another language and then when they get problems blame the language and not themselves.

    Anyway: how can you call a language complete if it does not have a GOTO statement ? I'm not saying that I use it a lot, but it is useful for handling errors & similar. I will doubtless now be flamed by those who have heard Dijkstra's complaint about GOTO and not understood it. I remember programs where one in every three statements was a GOTO - yuck, that is what he was complaining about; not about the single GOTO in every 1,000 to 3,000 lines that I seem to write. Yes: I could eliminate those GOTOs but either by making the program less clear (by introducing extra state variables, or similar) or by making it less efficient. His complaint was about excessive use of GOTO, many who have not read the paper, or do not have enough real programming experience, forget that important qualification.

    • by Mybrid ( 410232 )

      Perl has GOTO and LABELS. I used PERL mostly for ETL and having the capability to break out nested for loops using LABELS made the code cleaner not having to use a bunch of condition variables. Now that I'm in Python I have to filter things which means iterating over things once for the filter in the for list and then again for the processing. Things can be corrected by using 'yield' to iterate once with generators but, and here's the but, the Perl LABEL code is intuitive, whereas the 'yield' code trips peo

  • I'm sorry but I don't see the security problem, at all. All I see is a bunch of hyperbole.

    First thing one learns in security is that as long as humans are involved then you have a problem. RUST only addresses one aspect of human involvement, operator error. RUST does not address backdoors of design. The recent IOT attack the created the largest DDOS attack was such a back door.

    If the past is any indication of the future then RUST will find its niche and that's it. Safe malloc libraries have been around a lo

  • For the sake of discussion. I haven't used but worked with people who did. They said it was much better than C or C++. Can anyone weigh in on the pros and cons of Go?

  • I believe that we are about a decade away from a disruptive change that will obsolete all of this. The refactoring would probably take longer.

    At some point, we are going to change to a system in which neural networks are the system and a swarm of traditional processors running very small, tight, calculator-like algorithms are tied within the neural network. This merging of calculators, memories and artificial minds will occur long before any intensive augmentation of biological minds - likely in the next co

  • Swift (Score:5, Interesting)

    by johnrpenner ( 40054 ) on Sunday July 16, 2017 @03:33PM (#54820971) Homepage

    i've recently converted from C++ to Swift — better modern native unicode string handling, and scales really well from beginner semantics all the way to system level stuff. its a great language to work in — and written by chris lattner (who wrote the clang and LLVM compiler/architecture) — so its well fitted for performance optimizations/very fast.

    swift is the first language that i'd say i feel comfortable replacing C++ with.

    2cents from toronto
    john p

  • by GuB-42 ( 2483988 ) on Sunday July 16, 2017 @07:36PM (#54822217)

    The strength of Rust is that it has a great static analyzer.
    But C also has great tools : linters, debuggers, test frameworks, ... Use them. No need to rewrite everything.

You mean you didn't *know* she was off making lots of little phone companies?

Working...