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.
"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.
Yes, go ahead! (Score:5, Insightful)
Yes, replace billions of working C code with billions of lines of code in a new language. What could possibly go wrong?
Re:Yes, go ahead! (Score:5, Funny)
Well if this guy says so, what doubts could you possibly have left?
Re: (Score:3)
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)
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)
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.
Re: (Score:2)
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)
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:4, Interesting)
Most people have literally no idea what it would actually cost to prevent security issues and other bugs using formal methods. The average developer probably hasn't even heard of them, and I'd guess less than 5% of professionals have any substantial knowledge of the relevant tools and techniques or have ever actually used anything much beyond a type system for this purpose.
It may well be that organisations assume that the cost of prevention will be higher, but their ignorance is not an argument. (Neither is calling me names, by the way.)
Finally, your hypothetical $100K low risk vulnerability is irrelevant, given that within the past few weeks alone we have seen major security outbreaks with consequences like bringing down large parts of the NHS infrastructure in the UK, which probably cost lives and certainly caused a great deal of unnecessary suffering. Even the lower bound on the cost of security screw-ups in modern software includes people dying unnecessarily.
Re: Yes, go ahead! (Score:4, Insightful)
That means the first cost will be training a generation of developers in how to do it. Aside from assumptions, that will not be cheap.
And actually, their ignorance is an argument. Corporations are very allergic to costs they can't estimate in advance. It's up to the advocates to demonstrate that it'll be cheap, not to the skeptics to demonstrate that it'll be expensive. That's the way the world works.
Re: Yes, go ahead! (Score:5, Informative)
I work with a group that does formal verification and you seem also to be talking from a position of ignorance. Currently, the record for low-cost formally verified software is held by the NICTA team behind seL4. Their number is around 30 times the cost of using best practices for normal software development. A few caveats for this number:
There's a lot of ongoing research in this area (I quite like F*, though it has some significant issues with proof reuse and usability of its error messages), but the tools for formal verification are currently as appropriate for large-scale modern software development as punch cards.
Re: (Score:3)
The baseline is assuming the effort involved in creating a test suite with full coverage of the specification and a detailed specification.
The detailed specification is an often overlooked cost driver in this scenario. Customers really hate having to write detailed specifications and then being held to them.
Re: Yes, go ahead! (Score:5, Interesting)
A much better argument against formal regulation of the software development profession is that we don't know the best way to do it yet.
We have centuries of experience building bridges, and have a pretty good idea of how to build bridges that don't fall down by accident, even under unlikely but plausible conditions like freak weather events or excessive loading because the public ignore some limit or other.
We have decades of experience building software at all, and little consensus on the best way to do it. Indeed, we don't even have a clear definition for what "best" means in this context, and it's possible that depending on the purpose of and risks associated with software, a reasonable set of good practices might look entirely different in one case from another.
Worse, the people who are most qualified to judge when we do reach that level of maturity within the industry, and to formally recognise good practices, are probably among the least likely to actually do that. They're probably too busy building good software where quality matters.
Instead, there must be an all too realistic possibility that any formal regulatory system would be dominated by the famous consultblogauthspeakers who spend a career burnishing their profile within the industry, but who in many cases have remarkably little experience actually building working software of their own, never mind working software to a very high quality standard. The very last thing we need is these fools being given any real authority over developers who are trying to do better, or $DEITY forbid, being required to give their blessing to those developers before anyone can ship anything.
Re:Yes, go ahead! (Score:5, Insightful)
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)
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.
Re: (Score:3)
First, verifying the type system is formal verification, applying the results of a formally verified type system is still just type checking, not verification (except in the loosest possible sense of the word, with about the same level of accuracy as when the press says 'AI' when they mean 'algorithm'). A lot of verification works by reducing the problem to type checking, but in the case of Rust the guarantees afforded by the type system are not correctness according to the specification of yo
Re: (Score:3, Insightful)
I can never explain to people which things need to be validated in a safe manner in C, C++, or Java. Is Rust going to give me the tongue of a oceanside saltwater merchant, or open their ears?
Re: (Score:3)
Aparently he didn't seem capable of hiring sysadmins who are thinking about making things possible instead of trying to prevent others from doing their jiob to remain their position of power.
Re:Yes it is too much to ask. (Score:4, Interesting)
Why replace it at all? Why not just introduce new features into the c compilers, language, and libraries that just identify and correct bad patterns and practices?
Because at some point, you can't keep building skyscrapers on shaky foundations. If the underlying programming model in your language doesn't provide some useful guarantee in relation to the correctness of your code, there is only so much you can do. Even modern C and C++ are very far into the not-providing-guarantees area compared to many other languages that have been designed with correctness in mind and the benefit of decades more collective experience in the industry.
Re: (Score:2)
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
The Rust community worries me. (Score:4, Insightful)
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:The Rust community worries me. (Score:4, Insightful)
When I first heard about Rust and went to check it out, the so-called "community" put me off it completely.
Re:The Rust community worries me. (Score:5, Interesting)
Re: (Score:2, Insightful)
It's a language by and for SJWs. The real reason for its existence is to try to push out the older generation of hackers, whose politics they despise.
Re: The Rust community worries me. (Score:4, Funny)
emacs vs vim, obiously.
Re:Yes, go ahead! (Score:5, Insightful)
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
Re:Yes, go ahead! (Score:5, Informative)
Except that Rust is kinda a bit like C except with a formal verifier built in so you can prove you don't have memory errors
Please stop repeating this. Rust has a type checker. Most languages have a type checker. The type system in Rust is stricter than that in C (though it is possible to implement the same thing in the library in C++), but it is not a formally verified type system and the implementation of the type checker (which is not a formal verifier) is also not verified (and can't be until the type system itself is verified). If you want a language with a formally verified type system, look at Pony. If you want a language that integrates formal verification, look at F*. If you want to use Rust, that's fine, but stop claiming that it has features that it doesn't.
What happens to Rust when Mozilla is gone? (Score:5, Interesting)
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.
Re:What happens to Rust when Mozilla is gone? (Score:5, Informative)
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.
Re: (Score:3)
Re:Yes, go ahead! (Score:5, Interesting)
Doctor Whatever (Score:2)
It's almost like the rest of us are more interested in the future of systems programming than casting decisions on some television show. If this bothers you, maybe you're on the wrong site.
Re: (Score:3)
I would expect Slashdot users to post numerous variations on, "Is she hot?"
Re:Yes, go ahead! (Score:4, Informative)
Rust is not all that portable. Rust is tied to LLVM. There are a lot more platforms supported by, say, GCC than LLVM. For example, I'm working on some Arduino and Xtensa based stuff at the moment. No Rust support but C and C++ are both supported. It's also trivial to link between C and assembly or for that matter C and just about any other language. I mix C and assembly all the time in the work that I do. I don't need any overhead of garbage collection, bounds checking, etc. either. The C calling ABI is very well documented and supported on all but the lowest end microcontrollers. If I write a library in C, it can be called from virtually any language. If I write a language in Rust, i doubt that would be the case. The C runtime library is pretty trivial. I've written bootloaders with only a page of assembly before calling the main function. By bootloader I'm referring to a true bootloader, code that is the first code executed when a CPU comes out of reset, not something called by the BIOS but code that will at some point load the BIOS.
Ada (Score:4, Interesting)
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)
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)
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
Re: (Score:3)
#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.
Re: (Score:3)
There's a lot of good stuff here: http://www.adahome.com/ [adahome.com] and here: http://www.adaic.org/ [adaic.org]
And It's "Ada" not "ADA". The language name is not an acronym. Rather it's named after Ada Countess Lovelace, see https://en.wikipedia.org/wiki/... [wikipedia.org] The choice of the name was deliberate, Ada Lovelace is commonly cited as the first computer programmer (for Babbage's Analytical Engine). And that name long pre-dates the current initiatives for "women in computing." (There were a fair number of women involved with th
Re: (Score:2)
...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.
Re: (Score:2)
That's one. How many industrial-quality C compilers are on the market and what is their price range?
Re: (Score:2)
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$
Re: (Score:2)
Which is what I said ;-)
Always how it is in the aerospace and DoD worlds!
Re: (Score:3)
DB: HAL, I think I've detected a logic error in the main core.
HAL: I'll get right on that Dave
Re: (Score:3)
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)
Re: (Score:3)
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
Re: (Score:3)
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?
Re: (Score:2)
1. It's maybe 1 instruction on most architectures.
... some_array(index) ....
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
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
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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.
Re:Ada (Score:4, Insightful)
The particular interesting thing about -avionics- is the cost of development is dwarfed by the cost of verification. I remember a presentation by Boeing Commercial Aircraft on the 777. They said, "We've done DO-178b Level A in a bunch of languages. For most languages, the cost to develop and the cost to verify is pretty much the same. For Ada [Ada83 - this was in the 90s], the cost to develop in Ada was 25% more than other languages. But the cost to -verify- that Ada was about 1/4 the cost of any other language. DO-178b Verification costs up to 10x development," He wouldn't say just how much that cost for 777, but he strongly implied it was multiple billions of dollars.
Re: (Score:2)
What about Ada?
I came to this story to post this very question.
Re:Ada (Score:5, Interesting)
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"
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.
Re: (Score:3)
You are what you eat?
Re: (Score:2)
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
Re: (Score:2)
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
That's a bit rusty... (Score:2)
Or Ada. Or Erlang... (Score:2)
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
Re: (Score:2)
Erlang was originally developed to facilitate the creation of provably correct real-time communications systems. The argument (all the way in the dim depths of 2014 here on Slashdot IIRC) is that in today's world all software will eventually be connected to the Internet and both its interactions and its databases may be located at multiple remote unreliable locations/links, and hence all systems can be (and then proceed to should be) modeled as real-time communications systems requiring provably correct s
An embarrassing admission (Score:5, Insightful)
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)
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) {
}
Re: (Score:2)
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.
Re:An embarrassing admission (Score:4, Insightful)
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.
Re: (Score:3, Insightful)
If the only way you can document your code is "this may look wrong but it's not" You're a shitty developer.
Re: (Score:3)
Of course, a year after I left, someone modified the code and it started eating up ram. When they called me, I told them to put the code back the way it was, because even the source said "this may look wrong - but it's not. DO NOT TOUCH". They reverted to my old code, and everyone was happy.
So... from that anecdote, are we to conclude that C code is unmaintainable, your code is unmaintainable, or both?
All in all, your story is a great example of why C is bad. It took a long time to build something that worked correctly, and once completed the code is brittle and unmaintainable, to the degree that you felt the need to comment that it should not be touched. And you were apparently right. Also... the code could still be full of security holes. The fact that it runs correctly in normal circumsta
Bullshit slashvertisement (Score:4, Interesting)
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.
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
Re: (Score:2, Flamebait)
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:
Re: (Score:3)
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'
Re: (Score:2)
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.
Re:Bullshit slashvertisement (Score:5, Insightful)
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.
Re: (Score:3)
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
well, he's not wrong (Score:3, Insightful)
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)
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
Fix the code dont try a new language (Score:4, Informative)
Moving the goal posts doesn't eliminate them (Score:2, Interesting)
One is data structures: in C there are no data structures. Any memory can be
Formal verification my foot (Score:2)
Re: (Score:2)
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.
Comment removed (Score:3)
Re: (Score:3)
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
Re: (Score:2)
Misplaced blame (Score:2)
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
Re: (Score:2)
Yes, this. Now let's all trust MS Winders.
Re: (Score:2)
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.
So replace old and proven with new and unproven? (Score:2)
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
Many who code in C should not (Score:5, Insightful)
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.
Re: (Score:2)
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
C is not the problem. (Score:2)
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
What about Go? (Score:2)
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?
It's too late (Score:2)
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)
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
Use C with the right tools (Score:3)
The strength of Rust is that it has a great static analyzer. ... Use them. No need to rewrite everything.
But C also has great tools : linters, debuggers, test frameworks,
Re: (Score:3, Funny)
Well ain't that a self-confirming statement...
Re: (Score:2)
Sorry I am not discussing the anonymous coward behind it, but the statement itself...
"They just show up to post random nonsense and exhibit absurd biases" - that's exactly how I perceive the GP.
Re: (Score:2)
Ah, yes. Python, the language that pretty much requires its users to know what they are doing. Just like C, come tho think of it. All the hate against these languages comes from one corner only: Those that cannot hack it.
Re: (Score:2)
Not anytime soon. As in certainly not in the next 50 years. The little problem is that current AI is exclusively "weak AI". and that is the AI without intelligence. All it can do is statistical classification and that is not enough. So for the foreseeable future, the only thing that can make code secure is competent coders. "Pay peanuts, get monkeys" is the main problem that causes insecure code.
Re: (Score:2)
And that is just it. A C coder needs to be competent, or the code will be horrible. But the same happens in other languages, just that it is less obvious and that is a problem in itself. The problem are not the languages used, it is that there are far too many bad coders.
Re: (Score:3)
The whole point of this posting is that you should rewrite NetBSD in Rust. Without losing any portability. It is really quick and easy with such a modern and trendy language - you might even finish by next Thursday.
I expect it to work fine on a 6809.
Any failure will be punished by a lifetime PHP project.