Slashdot Mirror
How Linux's Kernel Developers 'Make C Less Dangerous' (hpe.com)
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."
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?
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
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?
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.
Disclaimer: Not my own words but as defined by some technology site.
I hear that's a very lean and robust language.
C/C++ is not an 'amateur night' programming language, it's not 'child proofed', it doesn't hold your hand like you're a child, you can write entire operating systems in it, and as such it's supposed to have access to anything and everything, and that just so happens to include mucking up the OS of the machine you happen to be testing your code on. 'Sanitizing' it, 'child proofing' it would take away that power and make it useless. At that point you may as well just be writing things in BASIC or some other interpreted language that doesn't allow you access to anything terribly powerful or important. I've never heard anyone refer to C/C++ (or languages of similar power) as 'dangerous' before. I think it more likely that programmers have become lazy, or just aren't educated enough to be responsible with a powerful programming language, and as a result we end up seeing code that's sloppy, ill-behaved, and 'dangerous' because of it. Just like people complaining about how bad drivers are (and that we should ban humans from driving and make them use automation instead, which is stupid), someone wants to take the power away, when the real, rational solution is better education/training/testing. Have schools become lazy in how prospective programmers are educated and how their knowledge is tested? Then lets fix that problem rather than making decent programmers (and drivers) live in a world where the ability to really be behind the wheel and in control of the machine is taken away from them, because some people can't cut it.
Some 20 years ago I was consulting for a company that needed $BigCompay approval to release software. While at $BigCompany I ran across an old boss, who flat out said "interview with us, you're in". I did.
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.
cease fire stand down.. leave the stinking oil in the ground.. the colonels of the kernel would do well to compile even 1 distribution that included what us lamo users use by default?.. thanks..
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Aren't most of the security issues with C related to crazy compiler optimisations?
it makes more sense to just raise the bar and make security consciousness a part of being a programmer than to rely on 'safe'-ty obssessed newage languages, imho, since a better idiot will always be made.
as far as C itself goes, it would probably be a good idea to incorporate a lot of the best practice idioms into the language itself. we already got #pragma once for example, but it could be taken further with compiler extensions, then from there let the ISO formalise the popular ones. C11 already has done a lot of modernising, so may as well keep the ball rolling.
So treat it like one. JavaScript coders should go work on Atom or something.
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.
Mimetics Inc. Twitter
People who do not know to build secure things with C should be prevented from talking about it.
This is the worst kind of a talk I've seen in YEARS. Mission critical systems have been written in C and they all work without idiots like him having to talk bad about it.
We have MISRA and the Barr Group Embedded C Coding Standard
Start producing code that passes those checks and I bet a lot of the 'issues' go away.
This sounds like an argument for spending 10x the effort of what it would take to, uhh, just learn C.
There is a growing culture of trying to use various techniques to save you from making simple and silly errors, at the expense of putting you into a fantastic position to make much deeper and more serious errors, by virtue of allowing you to handwave away having to understand the complexities of the overall system at hand. Most such techniques are usually nothing more than vastly overrated shims and hacks (looking at you, RAII).
I laugh every time one of these articles comes out. Someone, in at least a moderate position of respect, gives a talk/writes an article about safer C programming, and some Rustards try to spin it. This will dry up and be forgotten and we'll be right back to writing C. All hail the One True Language, C, and pour a hot bowl of grits down the front of your pants.
....kernel developers actually know how to use C.
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.
Lend me your comb!
C could be a lot better at being closer to the machine. It actually lacks several features in order to placate defunct architectures.
... unless you typedef them - WTF
* 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'-'a'==26
* 2s complement
* iee-754
* big/little endian
* define , >>>, >> and to remove undefinedness
. -- differentiate between logical and arithmetic shift * standardize functions for common ops
. - ror, rol, ctz, clz, parity, popcount, etc...
* switch for "strings"
. - use ~strcmp and ~bsearch (or if tree for small number of cases)
. . 1. *simplified versions of bsearch + strcmp
. . 2. compiler internally sorts strings
. . 3. could be extended to other non-integer types
* ability to define bit size of parameters and enums.
* function pointer types are inside out
* function pointers != lamba/block/etc... could be more efficient (ex. qsort)
* _Generic provides 10% functionality with 90% of the work (it sucks)
To name a few. Anyone else know of a "saner C" standard that makes most of the undefined-ness go away?
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.
...to the incompetent.
Slashdot, fix the reply notifications... You won't get away with it...
C is broken. Here is my analogy to prove to you why: C is a very powerful low level language, that has few guard rails to get in the way of whatever it is you are trying to do. It is like a giant wood chipper, in that it will easily eat up anything you feed into it: Oak trees, 2 x 4's, old couches, anything. It also has no safety mechanisms, like guard rails, kill switches, occasional mechanical inspections, etc. Would you consider ever going near such a device in the real world? Of course not, it would be far too easy to make one mistake and die horribly.
Why would you choose a language that is the virtual equivalent of a huge dangerous tool, when there are better options available, like Rust or Go? Oh, sure, you are a skilled and expert level coder and you would never make rookie mistakes with void pointers or buffer copies, but are you writing all the code at your org yourself? What about all the other bozos that you work with, you trust them not to screw up?
I grew up with C/C++, and it has a special place in my heart, but I also know that much better things have come along in recent years. Just because you grew up driving a 57 Chevy, doesn't mean it is better than a modern car with ABS, Air Bags, Cruse control and 42 mpg.
HA! I just wasted some of your bandwidth with a frivolous sig!
C was never made to give you everything you could build on top of it, just the bare minimum so that you could build stuff on top of it, like better libraries, tooling, higher order abstractions and all that.
If you believe anything, believe that the bootstrap for many of today's languages came from C, including C++. And if you think any magical new language can solve any problem, you should know that this is proof that C can solve any problem, because if can create a magical new language (or any abstractions thereof).
So suck on that and come back when you childish programmers learn to program with C.
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.
Assorted stuff I do sometimes: Lemuria.org
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.
When all you have is a hammer, every problem starts to look like a thumb.
At work we write tons of C++ code. No memory leaks or memory corruption.
Someone had to write a utility handling some hardware and bought that it had to be C. Now customers complain that they have to reboot every few months...
Yep. The source of numerous buffer overruns.
Many, many years ago, I wrote a function that solved that problem. Internally, it called 'memcpy' but with a max number of items that was supplied in the call OR if it was missing, it used an application wide declaration which was usually '80'.
Worked well for me for 20+ years.
Other solutions are available and acceptable to me.
"Linus [Torvalds] likes the idea of always initializing local variables." That's new to me. I've seen and often requested myself many cases of redundant local automatic variable initialisation, don't remember seen any backlash against them.
Already used in operating systems, so we know it's powerful enough.
Verified C has three important features, of which two cover the issues from the original article.
First, it eliminates the ambiguities, although the current C specification has very few left.
Second, it is possible to guarantee correctness. Technically, this has been true for any C dialect for some time, provided you avoid ambiguous constructs, but this is easier.
The third feature, probably of greatest interest to embedded developers, is that the binaries can be proven to match the source in behaviour.
Because it is a dialect of C, with a known ABI, GCC will compile the code - sans the binary proof. Further, ld should be easily coaxed into linking VST-compiled kernel code with GCC-compiled code if it can't already.
So, if we went this route, we keep everything in C, we simply modify the more critical functions to use the Verified C dialect. Everything compiles as it did before, behaves as it did before, but we can now use formal methods to examine those functions.
Because you can use GCC, there's no risk of a performance hit although Verified C is said to be comparable to GCC.
Because we can do this one function at a time, you're not looking at a kernel rewrite but a normal-sized patch with each development cycle.
Just as security only requires a security kernel to be correct, you don't need to do safety checking over the kernel. So this approach needs only a tiny number of functions verified.
Is this the best solution? I don't know, but it's a proof that C can be made as safe as you like without impacting speed or functionality.
An alternative approach is for the Big Three (Red Hat, SuSE and Ubuntu) to agree to jointly fund two projects - one to properly document Linux internals, and one to properly test the hell out of it.
The cost would be peanuts to them, but systematic testing and systematic documentation would make finding and fixing bugs a lot easier. It isn't C that's the problem, it's digging around in C in the dark.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Spark (a subset of Ada for mission-critical work) would seem better, given that safety is apparent the concern.
I say apparently as I see no evidence safety is of interest at all.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
So all this talk of C/C++ being big boy's language and only a manly man should program it and it's your own fault if you write bugs is just so much bollocks. C and C++ are old languages and they have flaws that can be mitigated but not eliminated. That's Rust is so worthy of consideration - it eliminates that 50% of bugs by design and compiles with performance equivalent to C. Rust also makes it easier to write safe concurrent code, so performance can even exceed C/C++.
That said, I understand why the Linux kernel is kind of stuck where it is, but for new projects, or existing projects undergoing major rewrites, I would at least evaluate Rust first before defaulting to a C language.
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.
SJW n. One who posts facts.
No.
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.
That's irrelevant. Rust isn't going to replace C. It's converting C++ devs not C devs. All the C devs who wanted a new language moved to C++. Since C++ has all the same faults of C while adding a few more, those same devs will move to Rust.
The rust proponents (popping up everywhere to announce what they've written) who've written new packages in Rust were not C devs, they were C++ devs. C isn't going anywhere, but C++ is in danger of becoming irrelevant.
I'm a minority race. Save your vitriol for white people.
Anytime someone brings up rust in a C discussion it (and s/h/it) can be safely ignored. Instead bringing up random idiot comments from other sites and elevating them to the summary here brings up the question of Hanlon's razor.
I say "both", in the case of our esteemed current crop of idiot editors.
Every language from assembler up has always been safe assuming infallible programmers. Competent is both too low a requirement and rarely true anyway. No programmer is ever infallible, we struggle to manage competent all the time.
That's irrelevant. Rust isn't going to replace C. It's converting C++ devs not C devs.
Yes very likely. I think at this point nothing will shift the C diehards except for retirement.
Since C++ has all the same faults of C while adding a few more, those same devs will move to Rust.
That's only technically correct (isn't that the best kind?). In practice C++ mitigates a lot of the faults of C (though technically doesn't remove them).
but C++ is in danger of becoming irrelevant.
Eventually perhaps? Obviously there's a lot of momentum in C++ right now, and it won't fade to obscurity any faster then C. Rust can certainly make things possible/practical that aren't in C++. Whether that's compelling enough remains to be seen, but it's certainly an interesting direction for native code.
Rust's still behind C++ in some important places, like nontype parametrics.
SJW n. One who posts facts.
The Linux Kernel is the most valuable piece of software on the planet, by a wide margin. It powers the vast majority of all computing devices and work on it was started when C was a perfect choice for system programming. Now finally some new system languages are coming along, but they are decades behind C and even more behind on big software projects like the kernel.
Before rust or anything other can take over we are more likely to see a shift in CPU architecture. Rust or something like that will probably take over when some new purpose built FOSS kernel come around and does away with truckloads of legacy stuff Linux has to deal with.
C is basically assembler in "a tad more readable" with assembler being nothing other than opcode in "a tad more readable". That the kernel still works seems to prove that their choice of sticking with c can't be all that wrong. And should c eventually be replaced, the whole kernel will be replaced, that just about a no brainer.
Linux thinks you shouldn't be using a debugger, because of you're doing kernel code you should know what your are doing at all times and if it turns out you didn't you should backtrack manually to find every aspect of the fault. This is hardcore shit not intended for wussies, this is the foundation those wonderful python applications run on. And I for one trust that the kernel team knows what it's doing. Their installbase seems to agree.
My 2 eurocents.
We suffer more in our imagination than in reality. - Seneca
I stopped reading right here. C and C++ are NOT the same damn language. There is no language called "C/C++" either.
It's the first sign you have ZERO clue of what you're talking about. They might have a common ancestry, but they're not the same.
It's about the same if you had say a brother named Robert and I just decided one day to start calling you Rick/Robert. Since you know, the two of you look pretty similar, right?
every modern language is safe from buffer overruns assuming a competent programmer.
Even for incompetent programmers, ASLR and other protections in the OS layer protect you from buffer overflows to a surprising degree.
A good programmer will write good code in any language. A bad programmer will write bad code in all of them.
"First they came for the slanderers and i said nothing."
The trouble with making bridges is that you have to know what you are doing. If you don't know when to weld, where to weld, or where to place an arch, well its just dangerous. Arguably, you could just make a bridge-building kit that takes away most of the design work and every bridge would be exactly the same.
Yet, we make bridges various ways. We expect engineers to know their craft and avoid the mistakes. We use various simulation tools to test the designs. The same is true with all disciplines...doctors, space engineers, etc. It's important that we not remove skill from the software development process because a disturbing trend today is to make all things accessible to anyone who has not learned the necessary skills. No one wants to pay for a $250K engineer with 2 decades of experience, they want someone fresh out of school at $90K because now you can throw them in some managed code and get a result that still runs. It's hard to think of other skilled trades where the job market favors the inexperienced and unproven with highly complex engineering tasks.
Who will be migrating the giant software from a C language to a 'stronger C' language?
The implication here seems to be its not possible to meaningfully improve on C. Which is absurd, the question is whether it improves on C enough, not whether it's an improvement in the first place.
Nice in theory to have a team where all programmers are competent, but on large projects this does not happen, and even competent programmers have lapses.
This is a simple algorithm: find better C programmers! What idiot programmer uses a variable before setting it? When a programmer is "omitting break in a switch," https://www.hpe.com/us/en/insights/articles/making-c-less-dangerous-1808.html that's not a shortcoming of C, it's a shortcoming of the programmer.
From the provided link: 'Why does memcpy() have no "max destination length" argument?' Seriously? If you want to copy "a" to "b" and avoid overrunning "b", do something akin to memcpy (b, a, min (bytes_in_a, sizeof (b))), where min() returns the lesser of its two arguments. This isn't rocket science, people, it's skilled coding.
If you are a C coder who is too lazy or stupid to follow sound programming principles, then you should switch to a less demanding language and leave C to the expert coders.
Circle the wagons and fire inward. Entropy increases without bounds.
Delphi Object Pascal outperformed MSVC++ in Sept./Oct. 1997 Visual Basic Programmer's Journal issue titled "Inside the VB5 Compiler" in 4/6 tests (tying 1 w/ MSVC++ (both MSVC++ & Delphi lost to VB5 in ActiveX form loading)) - especially in MATH (by double) & STRINGS (by 4-5x) & EVERY program works on those.
* NO C/C++ BUFFER OVERFLOW POSSIBLES EITHER due to null-terminated string use - Pascal has length built-in to strings = why (so Object Pascal's safer - especially since even modern C++11 or better std. is NOT fully available in ALL C++ compilers fully implemented).
APK
P.S.=> It's the reason I chose it for my hosts file engine (better performance by default - ESPECIALLY in STRINGWORK) - hosts file work is largely stringwork (safer too due to the above)... apk
It was actually a yes or no question.
Bingo Dictionary - Pragmatist, n. A myopic idealist.
Rust has done one thing EXTREMELY well - hype. 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.
The only way you get buffer overflows these days is if you turn OFF the standard warnings, and use deprecated functions, while writing C. So Rust's "claim to fame" really just comes down to "on one very specific point, it's safer than C used to be back in the 1980s".
I've looked at Rust enough to know I don't want to use it any more than I want to wipe my ass with a cheese grater. I don't have to test that out to know it's not a good idea. They have done a phenomenal job of hype, though, comparing it to 1980s C. Guess what - C in 2018 also isn't 1980s C, every modern language is safe from buffer overruns assuming a competent programmer.
I fully agree on this. And I do write software in C, including, for example, some long-running pretty large multi-threaded demon recently for a customer. You only code buffer overflows in C these days when you are reckless or incompetent. The problem the Rust fanatics cannot see is that reckless or incompetent people will write bad Rust code too. The bugs will just be much harder to find than buffer overflows, which are pretty easy to find with modern tools. Fuzzing, higher compiler warning levels, looking for use of known-to-be-unsafe library functions (strcpy, e.g.), code-review of candidate code snippets, etc. all work well.
Getting rid of buffer-overflows in a language causes as much and possibly more problem than it solves and just makes some people think they can write complex code in Rust "safely". Not so. For example, botched access right handling in business code (something I see regularly when reviewing code) is a much worse problem than a buffer overflow and Rust can do exactly nothing about that. It is hard to find, but if somebody finds and exploits it, there is no warning. No crash to indicate something went wrong. The promises made by the Rust propaganda are mostly lies, often not directly, but in what is implied.
Rust does not turn a bad coder into a good coder. It does make bad coders much more dangerous, because now the bad coder cannot make some obvious mistakes anymore that would nicely point out their lack of skill. Now the bugs become subtle and the code runs just fine when somebody attacks them. The problem really is that the designers of Rust do not understand code security at all and that the "leadership" behind Rust probably believes they can now hire even cheaper coders than the incompetent bunch they were using before. Buffer overflows in code are a problem, but much more and much more importantly they are a symptom of bad coders.
Now, I am well aware that Rust does some other things and some of them are quite interesting for assessing code quality. They are a complete fail at improving code quality, because they miss the root-cause entirely. What Rust essentially does is allow bad coders to hide longer.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
C++ is also a much worse language than C. Its design is overly complex, its performance when you really use OO is problematic, the access rights are a mess, it suffers massively from the "second system effect", etc. You can basically only use it as an example how to not design a language. IMO C++ should definitely not be used by anyone. Going from C++ to Rust, I can see why people mistakenly believe Rust is their salvation. They flee a disaster area for something that works moderately well. And probably a lot of them believe the marketing lies that come with Rust and think they can now finally produce good code. Competent C coders do not care though.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
A good programmer will write good code in any language. A bad programmer will write bad code in all of them.
And that is the key insight. The Rust fanatics think that they can magically change that, like countless other morons in the history of coding. It never was a tool problem and, unless we get AI that can code well one day, it never will be a tool problem. It is a problem of insight and skill. What I really din't get is how these people can ignore all the evidence. In all other engineering fields, it is well known that the primary safeguard against problems is a competent engineer and that everything else just helps to improve efficiency, and can only moderately improve safety and certainly cannot replace insight and understanding. Just some larger faction of the coders believe in their technological field is completely different and that eventually there will be a "silver bullet" (Brooks, 1975), that finally will make coding an activity where they do not screw up. Well, of course they will continue to screw up, because they are mistaken about where the core problem is.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Your last sentence PROVES why rust will never be used mainstream.
Good programmers who write for the kernel CHOOSE to use C still to this day. Decade after decade we keep asking "why don't we write the kernel in...it's safer". And the kernel devs keep telling you guys NO. We write good code in C and like it. Deal with it.
but C++ is in danger of becoming irrelevant.
Eventually perhaps? Obviously there's a lot of momentum in C++ right now, and it won't fade to obscurity any faster then C.
C++ doesn't have a flagship project that is currently one of the most important and foundational projects of the software world like C does (Linux kernel), which means it can easily fade into obscurity and be relegated to niche projects. The ongoing work on the Linux kernel ensures that C isn't going to fade until the kernel code is replaced with something else.
I'm a minority race. Save your vitriol for white people.
Keep programming in C, folks, you will keep QA engineers employed forever!
> Rust does not turn a bad coder into a good coder.
The point of Rust is to allow good coders actually write better (not perfect) code. With C, good coders still manage to write bad code while thinking they are golden. That is the entire point of the article, which you seem to have glossed over.
Don't worry. No business coder is going to pick up Rust and start writing bad kernels and drivers. That won't happen.
I suggest you actually read the Rust book.
https://doc.rust-lang.org/stab...
It is a good read even if you don't plan to ever use it.
For someone who has clearly not given Rust a proper look, you have way too strong opinions.
C++ doesn't have a flagship project that is currently one of the most important and foundational projects of the software world like C does (Linux kernel)
All that C code is compiled with GCC which is now written in C++. Sometimes it's compiled with LLVM which the clang front end and the back ends are in C++.
SJW n. One who posts facts.
C++ is also a much worse language than C
that's an opinion and a wrong one at that.
Its design is overly complex, its performance when you really use OO is problematic, the access rights are a mess,
Sure, bt it's still a much better choice than C.
You can basically only use it as an example how to not design a language. IMO C++ should definitely not be used by anyone.
Yes, well your opinions are silly becase it seems you'd rather micro-manage your computer than automate the task of managing it. Whatever floats your boat I guess.
SJW n. One who posts facts.
> "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."
Said the zealot without offering anything concrete to back up his beliefs.
Q: What's the difference between a militant fundamentalist and a RUST programmer? A: You can reason with the militant fundamentalist .
Is it true Alt-Right are terrified of RUST Programmers?
Sorry but we're too busy to learn every technology some opinionated asshole tells us we absolutely must learn. I did look at RUST and decided it's overrated and not worth learning. A case of 'who ordered that?' Far better ways I can use my time.
RUST beat people who decline to get on the RUST hypetrain sticks and pitchforks. Python is extremely popular but Pythonites don't need to to use sticks and pitchforks because Python sells itself.
Your arrogant zealotry only turns people off.
See subject (others told you the same) & I used shortstrings 255 char length (the limit of hosts/domain names in hosts) & I got more performance actually using those + short int length where possible (vs. std. integer or bigger sizes) to keep them on the local stack & if/when possible, in the CPU L1/L2/L3/L4 cache for data also so it processes faster (vs. going to global heap slower system RAM).
APK
P.S.=> So what you said WORKS FOR ME for better performance (but it's not the default to be 255 char ShortString in Pascal (FreePascal OR Delphi))... apk
I once read a (semi) humorous list in a local computer publication. I was in the 80's so I can't attribute and beg forgiveness. The comment was basically that C could be thought of as a 5,000 hp motorcycle, being the single fastest way from point A to point B, if you knew what you were doing. If not, it was the single fastest way into REALLY, REALLY, REALLY BIG TROUBLE.
We were discussing the issues of uninitialized variables before C ever was an ANSI standard. The consensus was that you initialized your variables on declaration and if for some reason you could not initialize the variable upon declaration, you did not use the contents of the variable until you did assign it a value.
So how is this a problem today? Powerful tools are absolutely dangerous. If you can't work with powerful tools safely, then don't.
When I repaired electronics for the military, I had to work around devices that would operate at millions of volts (Electronic Warfare devices). If I screwed up, I would become ash instantly. You just can't do powerful things without dangerous tools. Untrained personnel should not be working on such devices and yet with software, we have the equivalent of 5 year olds working with millions of volts.
Not everything can be made safe, childproof, or foolproof and if you try, you will find that you have restricted yourself so much that you can't get anything done.
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen