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."
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.
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.
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.
If you ask that, then you do not understand the target application.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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."
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.
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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
For one, Linux is written in C already. For another, Rust comes with an ideology. C doesn't care.
Looks to me like these people just want their "safe space" in the kernel, where nobody tells them off for having coded something stupid.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
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.
People who say "sheeple" have about as much sophistication as an AOL user, and in fact are probably actually AOL users.
Yes. They added defects to the language in the name of "undefined behavior" (aka UB). It's basically impossible to write a program in C or C++ that's 100% free of UB. The industry average is about 15-50 bugs per KLOC, and even the best companies openly admit that their code probably contains at least 7 bugs / KLOC.
Segfaults and signed integer overflow are the most common UBs infecting most of all C and C++ programs. But on the one in a million chance that your program doesn't contain one of those UBs, then the odds are good that you still have UB caused by type punning / pointer aliasing that "works on my computer," but will eventually cause your program to emit nasal demons when a new compiler assumes you didn't alias.
Personally I think optimizations around null pointer dereferences are symptoms of the worst form of brain damaged stupidity and/or intentional malice in compiler developers: basically, the compiler is allowed to remove branches testing for segfaults if it can prove that you will unconditionally dereference the same pointer later. And instead of emitting an error and telling you at compile time that it has statically proven that you messed up, the compiler writer is happy to just silently emit code he knows contains UB, and that he knows will result in nasal demons.
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.
http://saveie6.com/
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 its lack of a real-time garbage collector, instead relying on a mix of static analysis and reference counting.
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.
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.
Why not Ada?
Domestic spying is now "Benign Information Gathering"
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.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Have you written anything in Rust?
When all you have is a hammer, every problem starts to look like a thumb.
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.
When all you have is a hammer, every problem starts to look like a thumb.
Ah, the old "you don't know it until you try it" fallacy so dear to fanatics of all kinds.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
....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.
I donâ(TM)t know what I hate more...iphones, or the fact that slashdot doesnâ(TM)t support Unicode.
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?
Mostly because "I code in Rust" sounds pretty dumb, I would suspect.
On Linux, C most certainly does. The most widespread and popular compiler for C is GCC, a project that was formed *entirely* for ideological purposes, by a group that was formed entirely for ideological purposes, by one of the most ideologically die hard people in the software sphere. Hate it when people try to use euphemisms and dogwhistles instead of just saying what they mean.
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
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.
<p>Even embedded is mostly C++ now.</p></quote>
(start rant)
I <i>wish</i> it was mostly C++. It may be C++ in the higher power MPU world where software more complexity brings in people with more opinions, but in the smaller world (sub 512k ram, 1m flash) it's still mostly C. In the even smaller embedded world at the sub (16k ram, 32k flash) you'll find it is all done in assembly code. And that world is inhabited with programmers who have their heads stuck up their asses so much they wouldn't know an object if it slapped them in the face.
I help with a framework for 32-bit controllers. The sub 200Mhz, sub 2mb flash type, and its all done in C. Why? 'Our customers are afraid of c++'. So we try to write complex code that works like OOP in C. You can do it, but its soul crushing.
Namespaces in C++ are worth switching from C to C++ alone, even if you don't use objects. If you're talking about a mildly complex system, the name mangling that comes with C++ and namespaces help to reduce collisions in names. Or else you start doing what we're forced to do, build the namespace into the function and variable names.
The syntactical sugar of objects, overloading and polymorphic code is just gravy when you have 40+ developers working on code and colliding name spaces. And when you start to deal with the requirements of supporting n-number of hardware devices and drivers using interface classes are better than naming your function pointer tables that you use under the hood something something vtable.
No, customers are afraid of C++. So we jump though hoops writing objects in C to satisfy the fears, and take 10 times as long to write code.
I'll agree there are some aspects of C++ that should never come near an embedded project, especially with, lets say less experienced engineers (templates), but all this can be solved with proper code discipline and with people who know what they're doing.
Even our tools don't support C++. Well I lie, they do support C++ officially, but in my mind the support is so broken that its better off not supporting it at all. When you're debugging a child class, you want to see all the members, including the members of the parent classes. But no the debugger is so broken it can't do that. Stepping through a virtual function causes the debugger to get lost. How can you even say you support C++ in your debugger/IDE if it can't even do that? And its suppose to be a premiere embedded IDE?
(end rant).
IoT is still expanding, so maybe more complex things will become most of the embedded world, but there will still be a lot of really small embedded areas that are needed. I really do hope that things progress and C++ starts to handle most of embedded coding, at least for the 32-bit embedded world, I really do. Used right C++ is just as fast and optimized as well optimized C code. It's a tool like any other, and requires skilled people to use it well.
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. 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.
When all you have is a hammer, every problem starts to look like a thumb.
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.
Another alternative I'd think of is Erlang. Or Prolog.
For the future - think outside the box. And that may not mean C, C++ or any of the traditional procedural languages.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
It was a yes or no question.
So is "Have you stopped beating your wife?". A refusal to answer "yes" or "no" doesn't indicate anything useful.
I pointed out that the answer was an evasion. I believe it is apparent that the real answer to my question is "no". Is there shame in that simple answer, and if so, why? Nothing stops anybody from following up with "no, but..." However, evasion... just don't do it. The message you send is "the true answer to the question would be harmful to my argument".
In this case, "no I have never used it" could be followed up with "however I have researched the question a lot, and I have these other data points I can also offer..." But that didn't happen. So now I am left with the impression that the anti-Rust argument was just rhetoric, based on nothing more than personal prejudice.
For the record, I have not written anything in Rust, however I have researched it a fair amount, I have installed it, and I do intend to try some toy programs in it. So far I mostly like what I see, especially the rather impressive performance.
I understand that some significant parts of Firefox have been re-implemented in Rust from the original C++. And I notice that Firefox has improved a lot in recent months, particularly in terms not leaking like it used to.
When all you have is a hammer, every problem starts to look like a thumb.
Making them not language specific.
And did you write that C code?
When all you have is a hammer, every problem starts to look like a thumb.
...to the incompetent.
Slashdot, fix the reply notifications... You won't get away with it...
Don't engage that guy. He will throw illogical questions at you until you die of old age, and all the while think that every one you refuse to engage is a point in his favor. It's exhausting.
Totally agree on all points except one... I use YAML/JSON for all my configs these days. It's pretty damn useful to have a well-defined and well-known structured data representation format that you can edit with emacs
Eh, that's like saying a dude with an AK-47 in Syria subscribes to the ideology of Kalashnikov.
Your logic is borked, amigo.
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!
I wish it was mostly C++. It may be C++ in the higher power MPU world...
You put your finger on it, it is strongly dependent on how powerful the embedded platform is. This may alarm you
In that survey, C++ and C are in a dead heat. Obviously, C++ will be ahead of C next year and Python will probably be even further ahead. Shudder.
For my part, I was coding embedded for a 16KB part in C++ back in 1999, I think the compiler was Wind River. The development environment was the lap of luxury, that is, source level debugging using one of those JTAG wigglers. Operating system just coded inline, maybe about 300 lines. I had no idea this was unusual, so thanks much to whoever had the foresight to set that environment up.
The embedded world isn't like that any more. Now people think that a NUC is embedded. Now you typically run Linux, I think Linux is even running in my thermostat now. It certainly is running in all my TVs. Yes, there are still tiny embedded processors out there, particularly in toys, but it's a rapidly shrinking world, and there isn't a lot of new blood flowing into it. That may explain why you see a lot of attachment to old ways of doing things, like straight up C. And you see a lot of EEs in there, I think you know pretty much how open to change they tend to be.
When all you have is a hammer, every problem starts to look like a thumb.
Disclosure: I've worked on the Linux kernel.
Here, you never know who you're really talking to, do you? (Interpret that as you wish.) And do you support the claim "they all work" in reference to mission critical systems written in C?
My take on it: past a few thousand lines you basically need to be a rocket scientist to develop mission critical code, whatever the language. C makes it harder than C++. But C makes it easier than assembly.
When all you have is a hammer, every problem starts to look like a thumb.
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.
Have you been drinking?
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.
You show every sign of being intermediate level programmer who believes they have nothing left to learn. And remember, here you never know who you are talking to.
When all you have is a hammer, every problem starts to look like a thumb.
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 followed that up with your loaded question, giving no one reading any reason to think that you're doing anything but trying to fool a high-school aged kid into walking down that illogical chain of discussion.
"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.
Is Rust less dangerous than Verified C Dr the Verified Software Toolchain?
Do I have anything equivalent to Why3 to verify correctness?
The kernel, in C, can have critical components modified to fit the constraints. It's still C, GCC will still compile it, but I could then verify it. Without impacting performance.
Linux is big, if you want to convince me you cod write an OS kernel in Rust (remember, no standard libraries), start with rewriting SEL4. Whilst retaining or improving on the defect ratio and performance.
If you can't do something that small, you can't do Linux.
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)
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.
At the end it boils down to "you must know what you're doing".
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
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.
I think this is in many ways not correct, but there's quite a lot to unpick.
Fanbois aside (let's ignore them because they muddy all sides of the argument), no one is claiming Rust will solve all problems.
C, C++ and Rust all provide essentially the same machine model. Arguably Rust's is closer to C than C++ is to C since it doesn't need as much runtime support (for exceptions). But there's not much to it.
C++ provides a while load of automation on top of C and by virtue of that protects you from a lot of common errors if you use it in a vaguely modern way. Rust provides s buch of compiler enforced restritions which prevent a large class of errors (memory errors and data races).
You very likely have those problems if you write in C, and you won't if you write in Rust. You can abvoid those problems in C with one or more of formal methods (the seL$ model, very hard), large amounts of reviewing (the OpenBSD model---also hard), lots of runtime checking (imprecise). Or you can use a language which does it for you, though the penalty is that now ownership (which you can wing in C) is now front and centre because it turns out you can't magic hard problems away. You can however make them much less hard.
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
I think this is both wrong and right at the same time. Yes people don't change. Why then can we produce much cooler stuff at a much faster rate now than 10, 20, 50, 100 years ago? The answer is of course better tooling.
Switching from a foot pedal lathe with hand forged carbon steel tooling to a 6 axis CNC machine with auto loading, and auto switching of it's carbide insert tooling certainly won't solve all your problems. It still leaves you with the difficult poblem of designing something nice looking which works with real wood, and that people want to buy. But it certainly alleviates the tedium and hard work of continually cranking that foot pedal and sharpening the tools every five minutes. Which is what it's like programming in C.
It's a bad idea to dismiss tools that solve a lot of your problems merely because they don't solve all problems and while they're at it make you 6 inches taller, move like Jagger and turn you from 8==D to 8======D.
If you're expecting to make people smarter you may as well ask for that.
Brooks already had a chapter on it: "There is no silver bullet."
and yet, I can write programs of vastly greater complexity and that do far more stuff than almost anyone, possibly anyone at all in the 1960s. Why? It sure isn't because I'm some sort of megagenius. No, it's because the tooling is so many orders of magnitude better now than then.
There's nothing that will magically make a bad, badly managed, demotivated team start cranking out good software overnight. That's the silver bullet you're talking about. On the scale of decades however there certainly are things that mean ordinary programmers can vastly outperform maybe all but the best of previous years.
New languages are a way for very smart people to slowly trasfer productivity to much les smart people by creating things that mitigate human frailties.
And OSS has a real C fetishism. It's weird. I mean we have these vastly programmable machines operated ostensibly by programmers who are in essence people who automate things. and yet they are incredibly reluctant to automate any of the day to day tasks they do. I don't get it.
Funy thing of course is that now all that C code is dependent on C++. No good C compler remain that are written in C.
Rust is for morons
Well, good to know you;re thinking about these things carefully.
SJW n. One who posts facts.
So is "Have you stopped beating your wife?".
No, because that question implies a prior state, which a "yes" or "no" answer implicitly confirms. The "have you written anything in Rust" implies no prior state and a yes or no answer does not implicitly confirm aything.
SJW n. One who posts facts.
old imperative style programming, not things like pattern matching
Pattern matching is a control construct. How is it exclusive with imperative programming?
Ezekiel 23:20
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.
Oh please... Rust is for people that want to be more productive with their time at the expense of some additional system resources.
[citation needed] on the latter. AFAICT C, C++ and Rust have more or less exactly the same model of how computers work. I don't see any evidence that any one of them is more resource hungry than the other (possible arguments about C++ exceptions aside).
SJW n. One who posts facts.
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 review?
SJW n. One who posts facts.
Agreed... That is why I called it out as rhetoric/propaganda?
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.
Personally I think optimizations around null pointer dereferences are symptoms of the worst form of brain damaged stupidity and/or intentional malice in compiler developers
Lots of people think this. Those people are astonishingly arrogant. That means you.
Compiler writers aren't some cackling evil genius masterminds in some shadowy cabal figuring out how to make programmers hard due to language pedantry.
That's not how compilers work.
Optimisers are code analysers and theorem provers. First you write a code analyser which figures as much as it can about any piece of code, such as range of values, data flow, aliasing, etc. Then you plug in the rules (which is the language spec). You then provide a list of transformations known to improve speed.
The theorem prover then crunches on the data to figure out which transformations it can apply which don't change any of the known properties of the code.
Theorem are not human. They have no way of knowing which null pointer dereferences are bugs and which are not.
What you are asking is for the compiler vendors to do all those handy optimisations but then insert human-like intelligence into the theorem prover so it can know when one particular deduction at the end of a very long series of inferences should be flagged and when another is valid. You're then ragging on because they're not magicians.
they're not intentionally emitting UB they're emitting code that is correct provided that UB has not already happened.
SJW n. One who posts facts.
... with 20 years of experience in c and rust ...
Impressive. Should we read this as combined (19 years of C + 1 of Rust), combined total (10 developers each with 1 year of C and 1 year of Rust) or perhaps that you hired some time travelers?
Is there even a single line of rust in the kernel? There used to be some c++, but I think it's long gone now, or maybe left for some specific architectures...
Non-Linux Penguins ?
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.
Oops! Yes. My apologies.
SJW n. One who posts facts.
It isn't exclusively.
But it is generally considered one within the functional paradigms - paradigms which are increasingly incorporated outside the traditional functional languages.
C programmers are used to old imperative style programming, not things like pattern matching.
Surely C programmers can learn to use things like C++ compilers and std::vector / std::string.
Just using those three things would eliminate most of the problems highlighted in the article. The article is mostly about adding more layers of things to the code to avoid problems. The problem is that humans still have to remember to add those things every single time.
They should be trying to automate them away instead of adding more things to remember.
No sig today...
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
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."
It has nothing to do with "entrenchment" in a particular language. The kernel is written in C. Nobody is rewriting it an another language because that wouldn't just be stupid, it would be impossible.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
What is wrong with a simple "key value" config?
That problem was happening with C++ and Eclipse as well. We had a debugger for the PC version of an application. When it came to debugging code, the IDE would refuse to display the values of the variables you most wanted to see. Why? Because the build framework had all the optimization settings turned on, the compiler would optimize those variables into registers, but not store that in debug information. So the IDE couldn't figure out what the values were.
Companies are moving from embedded to mobile simply because the licenses are more expensive for a raw Linux embedded system than they are for Android. Plus Android offers all sorts of connectivity by Bluetooth for keyboards and gamepads as well as Wi-Fi.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Not talking about the use of C in kernels, drivers etc. C is good for that.
However, C is widely used beyond that since C skills are widely available, even if it is not ideal for many projects.
Rust is for morons with delusions that do not have what it takes but think they can write advanced code anyways.
Rust is for programmers who are willing to live with the fact that their codebase may have to be completely rewritten in that time as the idioms of the language are solidified.
If you're a startup which may not even be around in five years, the extra static analysis that Rust gives you over C may be worth paying that price. If you're maintaining a 25 year old several million-line codebase it obviously isn't.
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.
I'm pretty sure that nobody said that. What they said is that the specific problems outlined in this talk are mostly taken care of in Rust.
Contrary to popular belief, Rust isn't a moron language. Rust is the beneficiary of people who have been working on the "safer C" problem for decades; see, for example, Cyclone. It has a lot going for it, but it doesn't have the critical mass of long-term maintained code which makes it a safe bet.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
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.
No. Unlike you, I have actual insight.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Thanks, at least one person gets it.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
"Have you written anything in Rust" is the the starting point of a manipulative and fundamentally dishonest propaganda technique step here. Well, sure, the question looks innocent. It is designed to look innocent. What will build on any answer is not. "No": Next is some variant of "you don't know what you are talking about". "Yes": "You are doing it wrong" or "you have not gotten to the inner mysteries yet, continue to pray and you will be enlightened". It is all so transparent and inept, it is utterly revolting.
And it is completely wrong. The answer to that question is totally irrelevant here. Its only possible purpose is as described above. I am just ahead of you here and I have seen this despicable type of dishonesty enough to recognize it early. And I have seen it used to hype numerous other "silver bullet" technologies, none of which have delivered over time.
Which brings us the one important reason not to use Rust: The cult-followership it has. Such communities are utterly toxic and eventually destroy everything they touch, if not decisively rebuffed. And these cults do not even ensure long-term availability of their currently chosen holy tool. They may just move on to some other hype at any time and then anybody that really built on the old hype is screwed.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
1.) Obvious lie is obvious. Nobody has that kind of budget these days, unless the "team" is so small as to be irrelevant.
2.) Even if really done, border conditions are critical. Cheap coders will produce utter crap in C that does not even compile. They will screw up more subtly in Rust, which makes the code worse in actual reality, but it will look better with regards to the usual bad software metrics.
3.) This hugely depends on the problem space and surrounding environment.
4.) "Was a bit hard to find people working in Rust": That already removes any scientific validity due to faulty sample selection. You would have needed to look for C people that were "a bit hard to find" at the very least.
Just look at the scientific literature here. It will claim things (with evidence) like that C++ is going to solve all problems of C or that Ada is really the language everybody will be coding in by the year 2000 and that it will fix everything, or, going back, that C will finally remove all the problems of assembler. Nothing like that has ever materialized, but all these claims can and have been "proven" with the right, scientifically invalid, studies.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Opps, sorry. I read your claim the wrong way round. This way I get the joke. My apologies.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
Great point. I like YAML as a format, but when it's the only exposed interface for a black box that doesn't even give you control of order of operations, it's a curse. I'm specifically thinking of a case involving buildpacks for cloud architectures, and boy is that a circus of things Unix/Linux have long had right being reinvented badly.
I did, and hence why I use it...
JSON/YAML is actually *very* easy to parse.
XML- ya, I'm with you there.
Absolutely nothing.
But it's also very useful to be able to add structured data within those KVs.
I wrote my own parser that has very lax rules.
For example, quotes not required, nor even commas.
JSON can actually have correct formatting inferred very easily.
> 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.
The Linux kernel could be compiled in C++ mode for quite a while, a long time ago. The option was removed because g++ generated lousy code compared to gcc. (This is from memory, details may be wrong).
Finally! A year of moderation! Ready for 2019?
Rust is quite unpleasant to use (when last I checked) and was recently changing rapidly. It's also difficult to properly implement. C is easy to use (with problems), easy to port, and has lots of decent libraries.
FWIW, I don't like C, and consider it unreasonably dangerous, but my use case is very different. I do think that projects should adopt a subset of C rather than full C, and have a strong "super lint" to ensure that casting is done properly and void pointers have proper typing. (A macro preprocessor could be used to handle ensure that void pointers had semantic casts, that would be ignored by C.) This would take a bit of custom work, but not a huge amount....nothing like that required by the Mortran preprocessor for Fortran back in the day, as the notations would be a lot simpler...things like macros that translated into empty replacements, but which were recognized by the preprocessor. The terms would need to be defined by the preprocessor, so you could write something like:
a = func (C_INT_PTR p)
where p is a void pointer, and func requires an int pointer argument. This is something that could be done by convention, but you need the preprocessor to ensure compliance.
How far you want to take this is a matter of taste, but you could have a preprocessor that did a full type check if you wanted to put in the effort, and still have final output that is pure C code.
Perhaps the best way to do it would be to start off with a C to C compiler, and slowly add in additional checks, constraints, pre-defined semantic macros, etc.
I think we've pushed this "anyone can grow up to be president" thing too far.
> Every rocket scientist/insert one of your choice knows that C makes it possible to exactly build what they want as precisely as possible.
Scientists avoid C every chance they get. Too much plumbing. They prefer Fortran, Julia, Python, MATLAB etc.
> than rely on some elegant high level construction that will clearly just not work on every piece of hardware.
Rust just leaves that to LLVM.
> The first rust implementation was not written in rust, but in C++ https://github.com/rust-lang/r...
Actually, it was first written in OCaml. This was before it hit GitHub.
> You need to learn a lot of things before you come here and start trashing other people about your made up knowledge on what C is and isn't.
And you need to read the online Rust book before you understand what Rust is. Right now you don't.
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 arrays you have a different answer than if you need fixed length strings, and that's different than if you need immutable values to access between different processes.
But for the basic C use case I generally think certain features should be forbidden. Writing beyond the bounds of allocated storage sounds good, but is expensive to check for...and sometimes needs to be allowed in special cases (e.g., and array within a struct that isn't the final element), but in other cases (e.g. when the array isn't the final element) it should be normally forbidden....except that when it's a pointer based overlay on other storage...
C is full of misfeatures that are inherently dangerous. They allow you to do useful things, but those things should be done through some alternate mechanism, that isn't so liable to errors or abuse. I'm really dubious about all the features that allow you to address an indefinite amount of memory. I'm not sure that there IS a safe way to do that that is also efficient. (One way to handle that would be to allow the program to be loaded with a specified amount of reserved RAM, and if you need to exceed that, to do a save state, and then reload it with a larger specified amount...but allocation on the heap is probably less expensive.)
I think we've pushed this "anyone can grow up to be president" thing too far.
Standard Pascal strings were limited to 255 ASCII-7 characters. IIUC FreePascal has a variant kind of string that allows longer strings, and another variant for Unicode. Also a version for binary blocks. The Pascal strings could contain embedded null chars. (Well, so could the C strings, but the utilities would end the string a the first null.)
I think we've pushed this "anyone can grow up to be president" thing too far.
Standard Pascal strings were limited to 255 ASCII-7 characters.
But this hasn't been the case for decades. Try FreePascal or the community edition of Delphi to see the current state of Object Pascal.
> The only reason to use rust to write system code today is if it's ABI compatible with C.
Again, you don't understand Rust. Most C++ code today is better written in Rust.
> No argument for rust holds good unless rust can literally replace C
That's probably because you have not written any Rust code. You will like it, if you have some functional programming background. Else, it may take longer to understand what it brings to the table.
Rust does not have to replace C. C can stay C. But outside a very small selection of software that is best written in C, C is overused. Rust is a replacement for C in those areas.
> Nobody needs to learn rust
People just need to write non-buggy code and C is not helping. Rust is not the ultimate language. I can imagine better. And either Rust will further evolve or we will get other alternatives. But C is a dinosaur that only people who have invested decades of their lives and can't see beyond can love.
My main argument is not promoting Rust. It is about NOT using C, when it can be avoided. Too many people use C who should not be, for things that don't need C. I personally favor Nim, a somewhat obscure language and transpile it to C, over Rust. It better suits my needs. But I appreciate the amount of thought that has gone into Rust.
There will be a lot more expressive, high-performance languages coming out, thanks to LLVM making it easy to create them. These will replace both C and C++ in a number of areas.
Writing non-buggy code in Haskell is very different from writing non-buggy code in Assembler. Completely different strategies and paradigms.
Programming languages do significantly promote or reduce errors. You haven't even bothered to read the article (nor the Rust book). Yet you think you have an opinion.
Even experienced C programmers make errors that users of other languages simply don't make. You can have a lifetime of C experience. You will still make errors in C because it is an unsafe language by design. You can't eliminate all bugs, but you can eliminate entire classes of bugs by a more thoughtful language designs. We have learnt a lot in the decades since C about programming language design. You just haven't caught up.
If you think you are writing bug free code in C, it is only because either you are writing fairly simple code or your code has not been audited by a security expert.
You don't sound like you used any modern languages with sound type systems, let alone Rust.
Quotes from the article:
"Even if you're a C expert, as are most of the Linux kernel developers, you can still make killer blunders."
"C language itself has fundamental, unfixed bugs that await the unwary"
"C comes with some worrisome baggage, undefined behaviors, and other weaknesses that lead to security flaws and vulnerable infrastructure."
These aren't my opinions. These are consensus positions of C experts. They still use C because they have to. Most don't.
> nearly every operating system of note is written in C
z/OS is written in assembler ..
You sound like an old timer wistfully looking at some glorious past where you had a nice station.
The entire point of system design is to create tools that prevent errors. It should not take talent to do anything. We should take art and reduce it to a science.
If we know that people keep making certain errors, the solution is not to find the elite of the elite who have fewer cognitive lapses. It is to understand why the errors occur in the first place and eliminate them at the machine level, where we can reliably control things. This is system engineering.
Please don't be a craftsman. Be an engineer. Think like one.
"Civilization advances by extending the number of important operations which we can perform without thinking of them." - Alfred North
Make things easier so that we can advance to the next level of problems, rather than getting stuck in the old ones.
> These undefined behaviors are what C experts try to avoid.
Don't try to avoid them at personal level. Fix them, at the tool level. Else, people will choose better tools.
> Not learning why C works the way it is, makes a person a noob, not an expert.
C is just a tool. If it is not improving itself to handle the more complex problems the world provides, it will get discarded and people will look for other alternatives. It is a free world.
If C or C++ programmers want their investments to stay relevant, they have to innovate. But they have stagnated and others are picking the ball. The C/C++ communities are so lethargic that asking for even simple conveniences that do not impose any additional costs is too much. I think C and C++ will be generational things. Younger programmers will just move on to more modern, better designed tools. They won't put up with archaic ways of doing things.
I'll ignore the rest of the post because it is just frustration without arguments.
https://ruudvanasseldonk.com/2...
Again, what is this abstracting away? It outputs the exact same machine code as C compilers do. It is more mathematical. It is safer. It is more concise and readable. It is more explicit. It is better typed. Exactly, what is the complaint?
> people tried to abstract things away and then complain when their abstractions just won't work anymore.
Not sure what you have in mind. We are not talking about something like Haskell here, where abstract stuff is a goal onto itself, not the machine.
Cost free abstractions are good. There is no excuse in not having more of them available to reduce avoidable errors.
C control structures are abstractions. Why do you declare that we must stop adding further cost free abstractions to the toolbox? Is C some holy standard that must never be improved further? Is the risk of falling off arrays and strings so much more edgy, even when we now can avoid that at no cost? That way, we can call ourselves real men or women? This is like laughing at seat belts and air bags in the face of accident statistics.
No, accepting bitter empirical evidence for safety and employing safeguards is the mature, professional thing to do.
My startup implements cryptography that's safe against attacks by quantum computers. https://www.isara.com/ if you're interested.
This is relatively low-level stuff where we don't use much of the standard library, and we want decent performance. Part of our performance comes from doing clever things with the algorithms and the math behind them, but there's a lot of things that just take however long they take.
This is great for portability. From the start we've built on multiple platforms using multiple compilers and ports have mostly just been setting up the build environment.
When we started, I knew portability would be really important. I also wanted our code to be secure and correct. I looked into using Go and Rust but decided to stick with C for portability, mostly because they weren't ported to several of the platforms we thought we might need to support. We've also got a strong set of coding guidelines and a possibly obsessive-compulsive code review regime.
Since it was 2015, we decided to standardize on C99. Seems reasonable, a 16 year old spec should be widely supported... well, we build on Windows using gcc because Visual C's standards support is half-assed. We've run into platforms where you have to use the vendor's toolchain, and it's C89. Yeah, people are shipping new products built with customized gcc versions from almost 30 years ago.
We can't afford to have a tools group who can maintain ports of llvm and whatnot to various terrible platforms. So we do the best we can with C.
- chrish
Sigh. It isn't just junior programmers who keep shooting themselves in the foot, it is also the senior ones. It is their exploit-ridden code that makes the news, not a young man's college project.
My argument is: Your hammer is useful, but we found out that a lot of people are getting hurt using it, even experienced users. We know what we need to do to make it so that it does not hurt people. With some changes, it will be just as efficient, but safer. No, we don't need to dumb it down. This modern material is better and costs the same as your current one. Also weird: somehow, the users seem to think they can solve every problem with it. They even keep banging on screws. They think screwdrivers are for sissies. Anyway, there is this other hammer in the market with a rubberized grip.
Your response is: Nah! This is a classic design. It must always be like this, frozen in time, more or less. Users should just man up and blame themselves. Yeah we know; we made our hammer super slippery that it keep flying out of hands at the slightest distraction. But we won't provide a better grip. It is your job to find the right gloves if you need. Post alert signs. Wear helmets if you must, but that is your problem and choice. Join a special hammering class so that you can learn all complicated rules to measure humidity, sweat factor, swing speed, striking angle - things that increase the incidence of hammer incidents and oh mental exercises so that you stay alert and always on your toes. Hammering is for Jedis. We can't just put a grip and have it be safe for average Joes. We have a reputation to protect.
This isn't about the baby.
This is about the dads who keep walking off the cliff, all the same.
Quote: "Even if you're a C expert, as are most of the Linux kernel developers, you can still make killer blunders."
This is saying that there have been enough deaths that the canyon needs some guard rails - for child and adult alike.
This is saying that simply warning people and posting signs has proven inadequate over 4 decades. Time for new measures.
Or you have sections as in INI-files or most other key value configs.
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