How Linux's Kernel Developers 'Make C Less Dangerous' (hpe.com) 509
Hewlett-Packard's Enterprise blog summarizes a talk by Linux kernel developer Kees Cook at the North America edition of the 2018 Linux Security Summit. Its title? "Making C Less Dangerous."
"C is a fancy assembler. It's almost machine code," said Cook, speaking to an audience of several hundred peers, who understood and appreciated the application speed resulting from C... Over time, Cook and the people he worked with discovered numerous native C problems. To deal with these weaknesses, the Kernel Self Protection Project has worked slowly and steadily on protecting the Linux kernel from attack. In the process, it has worked to remove troublesome code from Linux....
With its operational baggage and weak standard libraries, C contains a great deal of undefined behavior. Cook cited -- and agreed with -- Raph Levien's blog post "With Undefined Behavior, Anything Is Possible." Cook gave concrete examples. "What are the contents of 'uninitialized' variables? Whatever was in memory from before! Void pointers have no type, yet we can call typed functions through them? Sure! Assembly doesn't care: Everything can be an address to call! Why does memcpy() have no 'max destination length' argument? Just do what I say; memory areas are all the same!" Some of these idiosyncracies are relatively easy to deal with. Cook commented, "Linus [Torvalds] likes the idea of always initializing local variables. So, you should 'just do it....'"
The long-term solution? More security-savvy open source developers... While at times, the idea of coming up with a Linux C dialect has been attractive, that's not going to happen. The real issue behind the problem of dangerous code is "people don't want to do the work to clean up code -- not just bad code, but C itself," he said. As with all open source projects, "we need more dedicated developers, reviewers, testers, and backporters."
LWN.net has its own run-down of Cook's talk, as well as a link to a PDF file of his slides.
"Sound good," posted one of their commenters, "though ultimately I'd like kernel devs to adopt Rust as their main Linux kernel development language. Beats the crap out of C and C++ combined."
With its operational baggage and weak standard libraries, C contains a great deal of undefined behavior. Cook cited -- and agreed with -- Raph Levien's blog post "With Undefined Behavior, Anything Is Possible." Cook gave concrete examples. "What are the contents of 'uninitialized' variables? Whatever was in memory from before! Void pointers have no type, yet we can call typed functions through them? Sure! Assembly doesn't care: Everything can be an address to call! Why does memcpy() have no 'max destination length' argument? Just do what I say; memory areas are all the same!" Some of these idiosyncracies are relatively easy to deal with. Cook commented, "Linus [Torvalds] likes the idea of always initializing local variables. So, you should 'just do it....'"
The long-term solution? More security-savvy open source developers... While at times, the idea of coming up with a Linux C dialect has been attractive, that's not going to happen. The real issue behind the problem of dangerous code is "people don't want to do the work to clean up code -- not just bad code, but C itself," he said. As with all open source projects, "we need more dedicated developers, reviewers, testers, and backporters."
LWN.net has its own run-down of Cook's talk, as well as a link to a PDF file of his slides.
"Sound good," posted one of their commenters, "though ultimately I'd like kernel devs to adopt Rust as their main Linux kernel development language. Beats the crap out of C and C++ combined."
Don't be lazy programmers (Score:5, Insightful)
Re:Don't be lazy programmers (Score:5, Funny)
I've never heard anyone refer to C/C++ (or languages of similar power) as 'dangerous' before.
I took a Numerical Linear Algebra class in which you were expected to use C. First thing the instructor said was, "This is not a class for children, and so you will write your assignments using C. If you can't be trusted with a pair of scissors, you definitely cannot be trusted with a chainsaw. C is a chainsaw. Deal with it, or come back next semester when the other guy will let you use the blunt scissors known as 'Pascal'." This was in 1986, BTW.
Re: (Score:2)
Yeah, in the 80s, they were having silly holy wars between C and Pascal. Fortran was the better tool for linear algebra code then.
Re: (Score:2)
Back then? There are linear algebra libraries still in use which is written in Fortran. Other languages just link to it, rather than re-implementing it natively.
Re: (Score:2)
That brings back memories. Our database theory lecturer absolutely hated any language with pointers or had to be compiled (C, C++, Fortran, Modula-2) and would constantly state that 4GL's like SQL, Prolog and Microsoft Basic were the future
Re: (Score:2)
I remember the first time I ever heard that some actual high-end commercial application software was written in BASIC; I think I almost fell on the floor laughing, thinking it was some sort of crude joke. Then imagine my face when I found out it wasn't a joke.
Re: (Score:2)
Well, you sure as heck don't want to use something like R for that, the class would be too easy. With the code in C, you'd have to actually implement the whole algorithm!
Re: (Score:3)
Re: (Score:3, Insightful)
> it's not 'child proofed'
Programming languages, in general, need to be human proofed. We have a ton of empirical data to support this for decades.
> 'Sanitizing' it, 'child proofing' it would take away that power and make it useless.
No, it does not. Programming languages like Rust allow you to do all the unsafe stuff you want. It is just that they are safe by default, but you can step out anytime you need to.
> I think it more likely that programmers have become lazy, or just aren't educated enough
Re: (Score:2)
Re: (Score:2)
Yes, there is a case for C in kernels, drivers etc.
But most of the C in the wild is for things that should never have been written in C in the first place - hence a lot of avoidable security holes.
Re: (Score:2)
IME nothing creates a security hole faster than the programmer thinking that just choosing Virtuous tools will somehow protect them from making mistakes.
The reality is that mistakes flee the light, but you still make just as many, being human. Like trying to reduce crime by increasing the policing of places with the most reports; it is easy to push the criminals from one street to another street, but much harder to reduce the crime rate.
Only an approach where the programmer has increased knowledge at both h
Re: (Score:3)
> IME nothing creates a security hole faster than the programmer thinking that just choosing Virtuous tools will somehow protect them from making mistakes.
To me, that would be like arguing that we should not have guard rails because they will make people complacent or that seat belts might make people drive recklessly or that if we make smoking expensive or inconvenient, people will still get cancers by other means.
Of course, there will always be the case of automation complacency and there will be other
Re: (Score:2)
And that is just the point. Kernels, drivers, high-performance software all are inherently unsafe. The only thing that can make them save is coders that really know what they are doing. These seem to be slowly dying out and the mediocre ones that follow want their safe space instead.
Re: (Score:2)
Unfortunately, C and C++ are used heavily beyond the kernels and drivers.
Re: (Score:2)
Re: (Score:2)
Who is talking about melting computers?
I am talking about bugs and security holes.
Re: (Score:2)
Programming languages, in general, need to be human proofed.
I call bullshit, and I'll put my decades of industry experience on that. Programmers need to fucking pay attention to what they're doing. There are no languages in the world that prevent the programmer from making serious structural mistakes. It's up to the programmer to know what the fuck they're doing.
Fuck Rust. Seriously.
Re: (Score:2)
The one thing that could be done (and was done in the past), was to allow each thread to sandbox the areas of memory that it was working with. You could use a couple of instructions that the programmer could use to instruct the virtual memory manager to lock out and unlock regions of memory that shouldn't be touched, so only the memory used by class objects could be accessed. Or it could be done intrinsically.
Any memory access errors would be trapped.
Re: (Score:3)
> I call bullshit, and I'll put my decades of industry experience on that.
I don't care for your claims of experience. I have been programming for decades as well.
> Programmers need to fucking pay attention to what they're doing.
Of course they do. "Attention" however has very weak reliability. This is a very well established fact by psychology studies.
> There are no languages in the world that prevent the programmer from making serious structural mistakes.
There are however programming languages that
Re: (Score:2)
Re:Don't be lazy programmers (Score:4, Insightful)
Dude, just search any software engineering journal. Unsafe languages make for more bugs. The design of the tool determines safety and performance as much as training, if not more.
> Now go back to play with VB or JavaScript.
Unfortunately people who happen to do unsafe code have this "eliteness" delusion. You are not smarter than anyone else. Write a large enough codebase and you will miss that buffer overflow somewhere, even though you know exactly what it is and have been on the lookout. Time and again, audits of well known software, written by very experienced programmers, show this.
People are not machines and make mistakes. The only solution is to design tools and paradigms where entire classes of mistakes are not likely to occur in the first place. The checks need not be runtime checks with performance penalties, but if you want safety and security in the end product, the machine checks must be quite robust. Don't ever rely on humans for that, pretending you have "competent" programmers. Prove, don't assert.
If programmers can't design languages that have safety features (with low costs) that everyone knows they need, how can anyone trust them to solve other domain problems?
Re: (Score:2)
Dude, just search any software engineering journal. Unsafe languages make for more bugs. The design of the tool determines safety and performance as much as training, if not more.
I read these papers. For a while. Then I stopped, because that is not actually what matters. Counting bugs is pretty worthless, even when you only do reliability and resilience. With security, it is basically completely meaningless. This is not the only area where counting-metrics give meaningless numbers.
Re: (Score:2)
Re: (Score:3)
> give some people more credit than you're giving them
Hey, I am not the one insulting people - OP thinks only C programmers are adults and the rest are children. I am saying that people are not that different. We all make mistakes.
> Jaded and cynical more than a little?
From psychology studies. I place low trust on human actors in any system. This is an empirically supported position.
> By your logic we shouldn't be able to have anything as complex and large as Windows or Linux
Not at all. C is intent
Re: (Score:2)
> I can avoid "unsafe" things in C simply by imposing similar limits to limits Rust imposes on what I am allowed to do.
Sure, except you can't do that reliably (you may think you do, that is not of consequence). Moving those rules from paper to software makes them enforced reliably.
> Calling people lazy and stupid and suggesting that only if they do what you want them to do they won't be lazy and stupid is not a winning strategy for getting anyone to care.
Read the post I was responding to. The OP was
Re: (Score:2)
> rust is political correctness
Rust is machine correctness. The forums are more about political correctness.
> c is the common sense way.
Nothing common sense about it. People just think whatever makes sense to them is universal common sense. C is the least "correct" (in terms of software engineering safety/proving etc) high level language.
Re: (Score:2)
Unfortunately, the believers in silver bullets will not die out.
Re: (Score:2)
> I've never heard anyone refer to C/C++ (or languages of similar power) as 'dangerous' before.
It is obvious you haven't been using C/C++ very long, Bjarne Stroustrup said this [stroustrup.com] about C and C++
There is even a famous book:
Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming [amazon.com]
Re: (Score:2)
You got room in your mouth for the other foot? Help yourself.
Re: (Score:2)
Re: (Score:3)
I think it more likely that programmers have become lazy
This. I've spent the last five years hiring software engineers. I've phone screened more than I can count. The Java programmers being churned out by university CS programs today are atrocious.
Pro Tip: If you mostly studied Java in college, you should go back to your alma mater and ask for a refund. No, seriously.
Re: Don't be lazy programmers (Score:2)
This is a ridiculous and terrible argument. The rest of the world advances both the tools and the education to make better systems that are more fault tolerant. The infrastructure in this world is built using better tools with what we learned from doing it the old way. You're asking for airplanes to be built only using hammers and screwdrivers instead of power tools and robots. C has it's place in this world. It will always be a great teaching language or for people that like to tinker close to assembly, bu
Re: (Score:2)
This is a ridiculous and terrible argument. The rest of the world advances both the tools and the education to make better systems that are more fault tolerant. The infrastructure in this world is built using better tools with what we learned from doing it the old way. You're asking for airplanes to be built only using hammers and screwdrivers instead of power tools and robots
The problem I have with this line of thought is lack of apparent outcomes commensurate with claims.
Obviously airplanes are built with modern technology using complex tooling. Some of the major assembly plants offer public tours where you can witness a small portion of it in action with your own eyes.
If "C" is just hammers and screwdrivers where is the equivalent of the modern plant maximally leveraging technology to churn out airplanes that couldn't possibly be done with hammers and screwdrivers? It seems
Re: (Score:2)
Re: (Score:2)
The "be a big boy" argument dodges the real question here: can a programming language be efficient (stay close to the metal) yet have sufficient checks and balances on itself? Would making it safer automatically make it more resource intensive*?
If there is an inherent and fundamental trade-off, and C (as it is) merely chooses the close-to-metal far spot on this spectrum, then the be-a-big-boy argument makes sense (assuming you want Linux "fast"). However, I've yet to see anyone make a strong argument that t
Re:Don't be lazy programmers (Score:4, Interesting)
I wonder if C or another language could not rely on API's or API-like expansion macros. A given shop would select the API's that fit its trade-off profile. If you wanted to skip pre-initialization for speed, you'd use the skipping version of an initializer API. And on the flip side, don't include the non-init API in the shop stack if you don't want accidental naked bits.
I worked for a company that did something similar......they wrote their own version of malloc() etc to avoid memory leaks. About a year after I started working there, the Javascript coders had to spend several weeks fixing all the memory leaks in their code. The C coders had none. Ignoring the problem doesn't make it go away.
Re:Don't be lazy programmers (Score:5, Insightful)
You know what really sets mature adults apart from wet-behind-the-ears kids? They accept that they're fallible.
Language safety got a bad reputation back in the 70s when I learned to program because language designers didn't know how to do it without getting in the way of ordinary work. So back then given a choice of K&R C or the Pascal dialects available, I'd have chosen K&R C because Pascal's strict type checking made common use-cases awkward. But there's absolutely no question that modern ANSI C's stricter type-safety makes it far better than K&R C.
You can't rely on a language to do your job for you, but you can certainly rely on a language to make your job easier.
Re: (Score:2)
you can write entire operating systems in it
You can write entire operating systems in many languages. C\C++ isn't special in this regard.
Re: (Score:2)
Most coders get to deal with fast processors, fast ram, and its always getting faster and faster. So sloppy programming can be covered with more overhead provided in more recent languages. Java & C# don't really have the concepts of memory allocation and clean up, that's all handled by the overhead. Python & Perl and other similar languages don't even need to worry about what types are passing through the sy
Flummox the interviewer (Score:5, Interesting)
One guy asked the standard string reversal question, in C. I put a pointer at each end of the string and walked them together. The guy was completely flummoxed, it was like he'd never encountered an answer he hadn't thought of. This was like the second question he asked me, we spent the rest of the interview me explaining my solution, he never understood it.
Guy turned out to be my sorta boss (matrix management means the guy you report to has no say in your performance review). He was a good guy, one of the early employees of the company, but as time went on I realized he did not understand C pointer arithmetic.
Mind you, this guy was smarter than me, and more driven. But he had never done assembly programming, hence he never really understood C pointers.
Me? Started with Z-80 assembly, moved to 8080, 8086, then 80386, which is when I learned C. Took to C pointers like a duck to water.
FWIW, the company I was consulting for never paid me for my last month (2 bi-weekly paychecks). Lots of phone calls, meetings, and fights. Huge reason I quit consulting and went back to working for companies.
Re: (Score:2)
I use C pointers every day.
And I try hard not to accidentally learn to understand them. I've seen the code those people write.
Don't give professional tools to amateurs (Score:5, Insightful)
That is basically the thing that applies to C code and has applied to it from the beginning. In the hands of somebody that knows what they are doing, C is not more dangerous than any other language.
Re: (Score:2)
They are all "professional" tools by definition. Don't use unsafe tools unless absolutely necessary is the lesson.
> In the hands of somebody that knows what they are doing, C is not more dangerous than any other language.
Completely wrong. Even people who "know what they are doing" (most think they do, but really don't. C enables entire classes of problems that simply don't exist elsewhere), still make avoidable errors with C because they are only human. This is not really an opinion. We know matter-of-fa
Re: (Score:2)
You overlook that the language brings in a very small part of the difficulty of any software project. And, incidentally, depending on the application pretty much every tool is "unsafe". The advantage of C is that the incompetent coders fail early and obviously.
Re: (Score:2)
> The advantage of C is that the incompetent coders fail early and obviously.
Actually, it is the opposite. With C, bugs exist silently without generating either compile time errors or obvious runtime errors.
Re: (Score:2)
What do you mean - "believe"? That is not an opinion. That is a well-known fact. Unless you write exhaustive (and I do mean mathematically) test cases, you can have danglers and buffer overflows that can go undetected for years. Audits show this over and over.
C gets its performance by simply not doing much in machine checks. It expects the human to take over that responsibility. This is by design. The consequences follow naturally.
> you just clearly indicated that you are not worth talking to.
Ran out of
Re: (Score:3)
Yes, and C is neither a "fancy assembler" nor "almost machine code". These are statements of an ignorant person.
Yes, "we can call typed functions through" "void pointers" but we do so by declaring what that the pointer type is, and this is not possible because "Assembly doesn't care" but because it is useful. Seriously, this guy is an idiot. While I have no doubt "Cook and the people he worked with discovered numerous native C problems", I also have no doubt that countless programmers discovered them lo
Re:Don't give professional tools to amateurs (Score:4, Insightful)
Having used a fancy assembler, I agree. C is in a whole different class, because with that fancy assembler, most of what you do is find out about the target CPU and and low-level I/O. And you do that again for every hardware architecture. With C you just need to know the coding model of the language and the language itself is way more powerful than even the most souped-up assembler. Sure, there are a few fine details in C where being able to do any assembler variant is really helpful in understanding then, but that does not make C some kind of assembler at all.
I do agree that this guy is an idiot. He carters to all the coders that fancy them bad-ass but that cannot write solid C code and blame the tool for that.
Yes, it is a machine language (Score:2)
So treat it like one. JavaScript coders should go work on Atom or something.
Re: (Score:2)
Never Ignore Warnings/Have Strong Coding Rules (Score:5, Insightful)
Before I read TFA, I was expecting to learn something about C coding that I didn't before.
I learned years before to NEVER, NEVER, NEVER ignore warnings. Very smart people put in those warnings and you should take heed of them. The example given (initializing a local variable in a switch) is something that you should never do - initialization must always be done outside of conditional code. If the initialization value changes according to conditions, then initialize the variable at the define with an invalid value and then test for it when you use the value outside the switch statement.
Demanding that there must be a clean build with no warnings before code goes to QA is a great way of minimizing unexpected problems down the road (I have found that before QA tests any code, they build it and send it back if any warnings come back). It doesn't take a lot of work to fix warnings and if the coder doesn't understand the reason for the warning, then they should be educated as to the reasons why it is a problem.
There are a number of APIs and constructs (like strncpy, memcpy and VLAs) mentioned in the article that never be used as a matter of course. Their use should be laid out clearly in the coding rules/guidelines and it only takes a few seconds to add grep statement to a make file to look for specific APIs and terminate the build if they're found. I've done this for years for teams that I've lead and there's usually a bit of grumbling but when you explain the reasons why you should always get compliance.
From my experience, inadvertent coding (security) issues comes from not having a strong set of build (acceptance) and coding rules right from the beginning of a project.
Re: (Score:2)
Yes. At least "-Wall" and when some warning is really not an error (it happens), tell the compiler explicitly to ignore the thing at the specific place where it happens.
Re: (Score:2)
I can't count the number of times I downloaded some open source that didn't work out of the box, or had some bug, and when I went to fix it the compiler spit out pages of warnings... well, I don't roll like that, so I usually resolve all of those first. And the original bug is gone, like 85% of the time.
Of course, that means sending in a patch would be useless, but that is a whole different ball of earwax.
Re:Never Ignore Warnings/Have Strong Coding Rules (Score:5, Insightful)
I learned years before to NEVER, NEVER, NEVER ignore warnings.
This.
Amateurs fix their code until all errors are gone.
Professionals fix it until all warnings are done.
Re: (Score:3)
Professionals fix it until all warnings are done.
By writing
#pragma ignore warning 101
above every offending line ;D
Look at Embedded. (Score:3)
We have MISRA [wikipedia.org] and the Barr Group Embedded C Coding Standard [barrgroup.com]
Start producing code that passes those checks and I bet a lot of the 'issues' go away.
AKA.... (Score:3)
Seriously...C is an extremely efficient and powerful language, but it must be wielded by thos who know how to use its power.
Every time I thought I knew a little C, one of my programmers - who really knew his shit - would just blow my mind with some of his routines. Function calls that returned pointers to the next function (state-machine type stuff) just blew my mind first time I saw it used. Blindingly fast, but damned difficult to debug.
Even with my background in assembler, some of their stuff was just amaizing.
OTOH, I would never consider writing, say, an ERP app in C, but for kernel work, interface routines, etc. it just cannot be beat.
Re: (Score:3, Insightful)
> Function calls that returned pointers to the next function (state-machine type stuff) just blew my mind first time I saw it used. Blindingly fast, but damned difficult to debug.
The article is partly about avoiding such cleverness.
From the article: "You can do almost anything with C, but that doesn't mean you should. "
C is a "dangerous language" (in the words of the kernel developer) as is. The last thing one should be doing is to make it worse with black magic like this. If you want to get clever with
If only... (Score:2, Informative)
* stdint-style types for size_t, ptrdiff_t, etc...
. - allows better portability for embedded
. . 1. ex. size8_t for indices that won't exceed 255
* lacks largest integer register type
* vector types and extensions - use arm's naming (optional?)
* only single word tokens (ex. unsigned long long double complex)
* ascii only (ebcdic et.al are defunct) => 'z
same old, same old (Score:3)
There's nothing new here.
Different languages have their strengths and weaknesses. I've coded professionally in assembly, Plus, Pl/1, C, C++, C#, Perl, Python, Basic, Visual Basic, Java, Javascript, Bash, TCL, TK, and probably a few more I've long forgotten. Right now Java is a great fit for the problem domain I'm working in. Fortunately I can express myself well in it and the Java developer tools and ecosystem are great.
When C is the appropriate tool I don't hesitate to use it. But I don't hesitate to use my chainsaw when I'm cutting up trees either.
You just have to know what you are doing before you start the engine.
C is dangerous... (Score:2)
Re:C is dangerous... (Score:5, Insightful)
RTFA: "Even if you're a C expert, as are most of the Linux kernel developers, you can still make killer blunders."
If you think you are immune to C dangers, you aren't an experienced programmer at all.
Re: (Score:3)
If you think you are immune to C dangers
Never said that. Would be more like "If you pretend to be immune to C dangers...". Of course C has its dangers, but even more so when people think they can program in C because they're used to Java or another high level language.
C is beautiful (Score:5, Insightful)
Oh, I love C. In my mind, you cannot call yourself a programmer unless you have delivered at least one non-trivial piece of software in C.
Why?
Because C is the no-training-wheels programming language. It is the "I'm not saving you from yourself" language. And more importantly, it is the "I will do what you say, not what my compiler writers think that you maybe meant" language. C will do what you tell it to do, it is the original embodiment of the Unix philosophy. It doesn't second-guess the programmer. If I do that, the computers job is to execute, not to think I'm an idiot and can't write code. I probably meant to dereference that pointer, I probably somehow made sure that it's safe and if the compiler can't see it then it assumes that it is wrong, not me.
Such beauty.
Of course, like professional tools in the physical world, in the hands of amateurs they instantly become dangerous. Don't give a chainsaw to a five year old, ok? Not a good idea. And don't give dynamite to a teenager, or something will get blown up and you don't know what.
So is it dangerous? You bet it is. Does it produce insecure code? Almost certainly because very, very few people can actually handle that stuff safely. And no, I don't count myself among them, it's been way too long since I actually wrote code in C.
But there is something to the beauty and the immediacy of having a computer not trying to think for you.
Local variable initialisation (Score:3, Informative)
How about Visual Basic? (Score:2, Funny)
I hear that's a very lean and robust language.
Re: (Score:2)
If you ask that, then you do not understand the target application.
Re:Why not use Rust? (Score:5, Insightful)
Because the statement is hollow: "Sound good," posted one of their commenters, "though ultimately I'd like kernel devs to adopt Rust as their main Linux kernel development language. Beats the crap out of C and C++ combined."
You have no scientific proof. It is your opinion.
People have been attempting to replace C since it was conceived.
Sort of like the idiocy in configuration management systems I see today.
Lets throw RPM and well know configuration management tools we have used for the past 20 plus years like bash shell scripting and invent a way to configure boxes by adding not required additional daemons, Oh lets also throw in different languages and screwy config formats like YAML. That way we can boost the requirements on our resumes for higher salaries so we can make things incredibly overly complicated, to even updated a single .conf file in etc.
I call BULLSHIT on you CF Engine, Puppet and Chef admins.
Like these management systems such as puppet..etc....you have no proof these systems like rpm and C should be replaced for build, configuration or programming.
Other than the fact it wasn't invented by a very naive generation of idiots out of college who like to pretend the last 20 years of the computing industry was a mistake and really doesn't exist.
Just my opinion, but everyday I manage thousands of boxes with bash and rpms for config management. I also patch using the C language.
Works great, and I don't need to learn Ruby, YAML, or create daemons for clients, or secure their firewalls...or...
Well, you get the idea.
Re: (Score:2)
People have been attempting to replace C since it was conceived.
With some success. Today, C is relegated to a small number of (important) niches, like OS kernel, base libraries and... the list gets very short. Free free to add to it if you like.
Even embedded is mostly C++ now.
Re: (Score:2)
Source: Every single tab and string machine, robotic arm, and conveyor system in my shop uses C, and they were made last year
Do you actually know that, or are you guessing? I think you are guessing. Here is an actual survey. [vdcresearch.com] That was 2012, I am sure the gap is much wider now. A quick survey of job postings on dice.com supports this assessment.
You sound sincere enough, but you really ought to admit: 1) you are guessing and 2) your sample size is one.
Re: (Score:3)
Re:Why not use Rust? (Score:5, Insightful)
Re: (Score:3)
Looks to me like these people just want their "safe space" in the kernel, where nobody tells them off for having coded something stupid.
Re:Why not use Rust? (Score:5, Insightful)
For another, Rust comes with an ideology. C doesn't care.
Oh, C definitely has an ideology: Do anything you want, but beware the consequences.
Mind you, I'm quite comfortable with that. It's the kids raised on Java that shit their pants when they realize that C won't protect them from themselves. Since you can't (or at least shouldn't write an operating system in Java, they keep casting about for a suitable language that isn't C. But since nearly every operating system of note is written in C or a C derivative, I think we can safely assume for now that they're just chasing their own tales.
Re: (Score:3)
Kernel development deals with very low level concepts and most people don't undestand them. If you don't know what you're doing you will undoubtely make mistakes and since the OS is the layer on which everything runs mistakes in kernel code have rippling effects throught the system and all the software you run on it.
You could write Linux (the kernel) parts in something other than C but that won't save you from having to know the gory details
Re: (Score:2)
And GNu doesn't?
It is silly as Linus is not a communist nor does Linus or any of the Linux developers need to be part of the Mozilla Rust team and be under their guidelines to use their products.
I am not saying moving to rust is a good idea. The reason Linux is in C is because Unix was written in C and Linux has conservative users and developers.
Re: (Score:2)
Re: (Score:2)
Rust makes a bunch of choices (static type safety, static memory safety, reference counting, etc.) that have been made again and again before. They may or may not be slightly better than C, but they are not so much better that it's worth the enormous investment to switch over, retool, and retrain. To put it differently, if people are going to switch out of the C/C++ family, it will have to be to something that's substantially better than Rust.
One of the things that I think is absolutely idiotic in Rust is i
Re: (Score:2)
Rather than trying to make C "less dangerous", why not use a language like Rust? Wasn't it designed to essentially be a less dangerous C?
All these "safe" languages do is impose constraints limiting what you can do.
Re: (Score:2)
Re: (Score:2)
Mostly because "I code in Rust" sounds pretty dumb, I would suspect.
Re: (Score:3)
Regardless of which language you use you'd end up with C or Assembly in the bottom.
I'm not sure if Rust is the way to go or if some different language is better. VMS/OpenVMS is using a large chunk of BLISS [wikipedia.org].
Another alternative I'd think of is Erlang [erlang.org]. Or Prolog [toronto.edu].
For the future - think outside the box. And that may not mean C, C++ or any of the traditional procedural languages.
Re: (Score:3)
No one refuses to use Rust because of NIHS because they would not have invented C either.
The real reason is entrenchment. People are just used to old ways. Rust's borrow checker has a learning curve. C programmers are used to old imperative style programming, not things like pattern matching.
Re: (Score:3)
Re:Here's why...Not invented here syndrome (Score:4, Insightful)
The exact same thing could be said about them wanting to switch to something new instead of learning C! In fact, if you're infected with NIHS you'd never be able to use an older generation of tools, you'd always need to adopt a new tool even when the old tools are better.
Like people who need to use an app from some company so they can communicate, because email is "old."
Re:Here's why...Not invented here syndrome (Score:5, Insightful)
Nonsense. It is "if it is not broken, do not fix it." C is not broken and the majority of the kernel is already written in it. It is just a tool that requires you to know what you are doing. But that applies to kernel development anyways. Rust is for morons with delusions that do not have what it takes but think they can write advanced code anyways. They cannot. The language is not the main difficulty here.
Incidentally, the believers in "just use this great new tool and all your problems will be solved" have been around forever, and they have been just as stupid way back as they are today. Brooks already had a chapter on it: "There is no silver bullet." Yet time and again, some people with little understanding of what matters claim that their pet-tool is that silver bullet.
C was a great language 30 years ago. (Score:3, Insightful)
Re: (Score:3)
> Now if you're telling me rust does exactly that, it is just another dialect of C.
That is not at all what I am telling you.
https://ruudvanasseldonk.com/2... [ruudvanasseldonk.com]
It generates the same machine code as C, except with safer and more concise constructs.
I would say that you are arguing that we learnt no better way to do things in the last 4-5 decades in programming language research in terms of generating safe and efficient machine code. That is just absurd. C is a dinosaur that exists mainly for legacy and compat
Re: (Score:3)
To say "C is not broken" is to close your eyes to it's real problems. But it's only broken in the same sense that assembler is broken. It has features that tend to lead to code that is unsafe, difficult to debug, and difficult to understand.
C is an excellent design for a computer language, just not an excellent design for a programming language. And arguments about what makes an excellent programming language are never-ending, because different use cases yield different answers. If you need resizable ar
Re: (Score:2, Insightful)
Have you written anything in Rust?
Re: (Score:2, Troll)
Ah, the old "you don't know it until you try it" fallacy so dear to fanatics of all kinds.
Re: (Score:3)
The only way you get buffer overflows these days is if you turn OFF the standard warnings, and use deprecated functions, while writing C.
Hooboy is that ever wrong. You are scary.
Re:Have you ever stuck a fork under your fingernai (Score:5, Insightful)
The only way you get buffer overflows these days is if you turn OFF the standard warnings, and use deprecated functions, while writing C.
That's bullshit. All you have to do is access an array with an incorrect index. You won't get a warning for that. And you won't even get it flagged with a run-time check until you feed it the wrong data. You know like heartbleed.
IOW your claim is flat out false and implies you either don't program C or you're so misinformed about it that you're a menace if you do program it.
Like almost all languages, Rust won't normally have buffer overflows. They've hyped that so much it would make PT Barnum blush, acting like that's something special.
It's really not the most important thing about Rust. Though in fairness it seems that so many C hackers are so misinformed about their own language and still struggling that it apparently matters.
the borrow checker actually prevents a wide class of memory errors and data races. The former are interesting enough, though not common in C++ (I occasionally have some). The latter is much more interesting though. If I was writing high performance (multithreaded) software with irregular structure then I'd be very seriously considering Rust since it seems to be the only language up to the task.
I'm not though, so I'll stick to C++. I'm not naive enough though to think my language is perfect just because I learned it 20 years ago.
every modern language is safe from buffer overruns assuming a competent programmer.
That's a foolish claim because it's tautologically true while being misleading. Assembly language is free from buffer overrnus with a sufficiently competent programmer. In practice however everyone makes mistakes.
Re: (Score:3)
He was therefore on solid ground in implying that your question was meaningless, or at best, baiting him.
Let's recap.
Oh please... Rust is for people that want to be more productive with their time at the expense of some additional system resources. For the majority of software projects it is a good deal.
The comment he was replying to. That is rhetoric. You know what rhetoric is, quite obviously, because you accused this poster of exactly that.
Nonsense. That is just the propaganda the Rust fanatics put out.
This was his reply. It was factually correct. He called out rhetoric for what it was- propaganda.
You follo
Re: (Score:3)
It's because of the Not invented here syndrome (NIHS) - A mindset or corporate culture that favors internally-developed products over externally-developed products, even when the external solution is superior.
WTF? Unless you're working at Bell Labs, choosing C doesn't seem to fit into the "NIHS" you describe. Not even a little bit.
Re:Here's why...Not invented here syndrome (Score:4, Insightful)
At the level of kernel programming, you want a direct mapping of source code to assembly language, with no surprises or unexpected compiler optimisations - some early day compilers would pad out variables in C structures or even rearrange the order so it didn't match the source code.
With Rust, something like macro overloading would be a code obfuscatory dream.
Re:Here's why...Not invented here syndrome (Score:3)
With Rust, something like macro overloading would be a code obfuscatory dream.
And C macros aren't? So here's the cognitive dissonance that seems to exist with C advocates. It was applied to C++ and appears to applied unchanged to Rust too.
On the one hand the attitude is that good programmers don't need the hand-holding of Crust++. On the other hand Crust++ lets you write other kinds of bad code.
Make up your mind! Do you have good programmers or bad ones? And why on earth don't you have some form of code rev
Re: (Score:2)
Making them not language specific.
Re: (Score:2)
And did you write that C code?