The Internet Has a Huge C/C++ Problem and Developers Don't Want to Deal With It (vice.com) 663
What do Heartbleed, WannaCry, and million dollar iPhone bugs have in common? From a report: One bug affects iPhones, another affects Windows, and the third affects servers running Linux. At first glance these might seem unrelated, but in reality all three were made possible because the software that was being exploited was written in programming languages which allow a category of errors called "memory unsafety." By allowing these types of vulnerabilities, languages such as C and C++ have facilitated a nearly unending stream of critical computer security vulnerabilities for years.
Imagine you had a program with a list of 10 numbers. What should happen if you asked the list for its 11th element? Most of us would say an error of some sort should occur, and in a memory safe programming language (for example, Python or Java) that's what would happen. In a memory unsafe programming language, it'll look at wherever in memory the 11th element would be (if it existed) and try to access it. Sometimes this will result in a crash, but in many cases you get whatever happens to be at that location in memory, even if that portion of memory has nothing to do with our list. This type of vulnerability is called a "buffer-overflow," and it's one of the most common types of memory unsafety vulnerabilities. HeartBleed, which impacted 17 percent of the secure web servers on the internet, was a buffer-overflow exploit, letting you read 60 kilobytes past the end of a list, including passwords and other users' data.
Imagine you had a program with a list of 10 numbers. What should happen if you asked the list for its 11th element? Most of us would say an error of some sort should occur, and in a memory safe programming language (for example, Python or Java) that's what would happen. In a memory unsafe programming language, it'll look at wherever in memory the 11th element would be (if it existed) and try to access it. Sometimes this will result in a crash, but in many cases you get whatever happens to be at that location in memory, even if that portion of memory has nothing to do with our list. This type of vulnerability is called a "buffer-overflow," and it's one of the most common types of memory unsafety vulnerabilities. HeartBleed, which impacted 17 percent of the secure web servers on the internet, was a buffer-overflow exploit, letting you read 60 kilobytes past the end of a list, including passwords and other users' data.
Developers or Managers? (Score:5, Insightful)
I expect that there are any number of developers who would be happy to address those issues if their managers would only put enough time into the schedule to do so (and not go-back and demand enough additional features to squeeze it back out of the schedule).
It's not a deadline problem (mostly) (Score:5, Insightful)
I expect that there are any number of developers who would be happy to address those issues if their managers would only put enough time into the schedule to do so
This would account for a percentage of the problem but your argument is something of a cop out because it ignores all the other parts of the problem. You can give programmers all the time and resources in the world and if they used C/C++ these bugs still occur. People are imperfect and they make mistakes. Many programmers are inexperienced and don't know any better. These problems have been known about for decades and yet they still occur even with projects where there are no time deadlines like many open source projects.
Re: (Score:3)
There are a few points this article ignores.
1) The attack surface of C/C++ applications is huge, because pretty much every OS and major application is written in these languages. These are High Value Targets, so of course more vulnerabilities will be discovered in these pieces of software. Blaming C/C++ for that is like blaming water for drowning, an
Re: (Score:3)
Re:Developers or Managers? (Score:5, Insightful)
If you need more time to make your c++ code safe, you're increasing its cost. If the business can't bear the additional cost, you're out of luck. Maybe you're using the wrong tool for the job / setting?
Re:Developers or Managers? (Score:4, Insightful)
If you need more time to make your c++ code safe, you're increasing its cost. If the business can't bear the additional cost, you're out of luck.
So your business can't afford the cost of fixing the code, but it can afford the problems that are caused by that faulty code? Are you sure about that or are you just looking for an excuse?
Re:Developers or Managers? (Score:5, Insightful)
There is often ZERO ROI for fixing bugs.
Fixing bugs costs time and money. Clients decide who to go with based on time and money. So, if you spend too much time fixing bugs, your clients all go to your competitors instead.
You have to cut somewhere, and QA is the juiciest target. Once you win the contract, any bugs that your clients never hit represent money you saved that gave you an advantage over your competitors. Any bugs you clients DO hit but can work around, same deal. Any bugs your clients hit, and that you must fix, represent unexpected costs to you which you can afford because you got the contract. Any bugs you fixed in advance...it's impossible to know if they really needed to be fixed, so they were risks you took that could have cost you the contract.
If buyers weren't so keen on always going for the lowest bidder, the situation might be different. But as it stands, your business will fail if you spend too much time and money on quality during development.
So you must release bugs. To succeed.
Re:Developers or Managers? (Score:4, Interesting)
Depends on what you're doing. Sounds like you're talking about one off solutions. Regardless, you sound like like some c-level giving a speech to a dev team. We have thousands of customers, and unfixed bugs means cancelled implementation and cancelled maintenance contracts. Fixing bugs costs time and money, but so does developing an application. Maintenance contracts make up the bulk of revenue, and it's very dependable revenue when the product isn't buggy as shit. Keeping those contracts is what keeps your company alive and what keeps your investors happy.
Re:Developers or Managers? (Score:5, Insightful)
While there is some truth to your statement (at least in the managers eye's), this is a very common fallacy. My previous industry saw many companies that had that exact mindset and while in the short term it can work, long term it will guarantee the failure of a company. For every bug, hack, and poor design choice the company is taking on technical debt. Up front, yes, the first and most important thing for new companies is securing jobs/contracts. Therefore one can afford and may even require a fair amount of corner cutting early on to accomplish that goal to establish initial footing (as said many times, no project has an infinite timeline and infinite budget).
If however that mindset is retained once a company is established the technical debt will accumulate and compounds exponentially over time. It also creates an entrenched mindset (that code has worked for years, no way it broke there!) that makes bug hunting and fixing much harder. Once that becomes the case said company gets a rep for having horrible buggy code that is difficult to fix. It then becomes trivial for the more expensive but higher quality products to take everything over. I know because I watched this exact scenario unfold. My previous employer definitely had their fair share of managers with the speed over quality mindset (I actually wrote a post about that yesterday...), but the overall company strategy was to put out higher quality products than competitors even though it was never going to be cheaper. It worked in spades. They were literally getting jobs to fix other companies' fucked up systems before the installs were even complete because the other companies' reputations got so bad. Keeping that code quality definitely required a lot of fighting between the architects/senior developers and management though (this actually contributed to me leaving that company).
There comes a break point of cost to profitability where that balance shifts to spending too much time/money on perfecting the software. Older game studios were guilty of that a lot I think (see 3D realms and Duke Nukem Forever), but from my point of view the balance has shifted to trying to put out too much stuff now without properly designing, testing, and fixing the underlying framework. It very much seems to be following economic modeling with supply/demand, but I think we are still in a highly volatile time because so much of the technology is new still (first to market is so valuable to businesses). So overall, I disagree that there is zero ROI to bug fixing and preventative measures, but both are undervalued and difficult to measure their ROI.
It's not the language, you stupid jackwagons... (Score:5, Insightful)
Nobody blames the 18-wheeler itself if the driver is too incompetent to load or drive it properly under most conditions, and nobody needs to go around blaming C/++, either.
If you're going to play that close to the metal (let alone doing anything further down, like, say, Assembly), at least try to know WTF you're doing, and get help if you're not sure. The more powerful and flexible the tool, the more dangerous (and less tolerant) things can get for the neglectful, the incompetent, and the ignorant.
Re:It's not the language, you stupid jackwagons... (Score:4, Insightful)
Re:It's not the language, you stupid jackwagons... (Score:5, Insightful)
What if the 18-wheeler were designed in such a way that it was very awkward and painful to check mirrors....
Then it is still up to the driver to be aware of and manage those limitations.
Re: (Score:3)
Re: (Score:3)
What if the 18-wheeler were designed in such a way that it was very awkward and painful to check mirrors....
But 18 wheelers *are* awkward, and regularly kill cyclists and pedestrians because they have awkward mirrors that are painful to use. We reacted as a society by requiring special driving licenses and regular health checks (at least in Europe).-
I think a solution to the problem is to ensure that programmers have access to well known paradigms that can be copy/pasted and by depending on well known libraries, and to use the existing tools that can analyze source code and computer code for known issues.
I do
Re: (Score:3)
But 18 wheelers *are* awkward, and regularly kill cyclists and pedestrians because they have awkward mirrors that are painful to use. We reacted as a society by requiring special driving licenses and regular health checks (at least in Europe).-
This statement proves my point and shows the flaw in the grandparents argument. Despite these issues being known and attempts to place a band-aid on the problem it still happens. At a certain point you need to fix the tool not the user.
Re: (Score:3)
If you're going to play that close to the metal (let alone doing anything further down, like, say, Assembly), at least try to know WTF you're doing, and get help if you're not sure. The more powerful and flexible the tool, the more dangerous (and less tolerant) things can get for the neglectful, the incompetent, and the ignorant.
Aren't you making the article's point for them? IIUC it boils down to: some languages are too difficult for mere mortals to handle, therefore they should be avoided unless you have a really, really good reason.
There's no licensure for programming so anyone can read up on C and call themselves a C programmer, and most managers aren't qualified enough to tell them they're wrong. In a world such as this, doesn't it become almost necessary to use languages that ensure the programmer can't blow his/her own fo
Re:It's not the language, you stupid jackwagons... (Score:5, Informative)
One of the big eye openers I had at a previous gig involved buying a Klockwork license and running it against our codebase. Granted it's still only static analysis, but I think it found close to 20K possible vulnerabilities about 1/3 of which were real (the other 2/3 were after any end user interaction, internal APIs, so that first third would be the interface side). Took a solid 6 months to address 90% of the issues and the other 10% required redesign of architecture to resolve.
Problem is those tools are *expensive* so most open source projects can't afford them and all but the huge shops don't want to spend the $$.
Re:It's not the language, you stupid jackwagons... (Score:5, Informative)
Problem is those tools are *expensive* so most open source projects can't afford them and all but the huge shops don't want to spend the $$.
Yeah, valgrind isn't all that expensive and can be run on all your tests. Any bug that then gets through vagrinded tests means that the test wasn't testing on or past boundary conditions.
Re: (Score:3)
and get help if you're not sure.
The people making those "mistakes" are sure that they don't need help.
Or do you really think people are such idiots that they stop every 3 lines of code and realize themselves: "Oh! I'm not sure about this! But I just write it this way!" ?
No, they are much bigger idiots, because they don't realize that they are not sure ... but that is actually not idiotic, or is it?
Comment removed (Score:5, Interesting)
Re: (Score:3)
For what it's worth C is especially awful because, in addition to the basic bounds checks every normal language has, so much of its behavior is "undefined", yet developers are actively encouraged to take advantage of its undefined behavior to achieve useful work.
No. "Undefined" nowadays essentially means that it is illegal what you are doing and nobody is encouraged to take advantage of it. It depends on the compiler what happens: Often the compiler assumes that "undefined behaviour" cannot happen and it can use this fact for optimization. But alternatively it could also add a run-time check, e.g. for bounds checking.
Re: (Score:3)
Unless using pointers, then it will teleport the bullet to another foot you didn't realize was attached to you...
Re: (Score:3)
The best minds have worked on some of this software, e.g. OpenSSL. That didn't prevent things like Heartbleed.
The best minds did know what they were doing, there was code that zeroed out all the data between calls. The person who picked it up later and saw a huge performance improvement by removing the code that wrote into the buffer twice is what caused the problem. So again, if you use bare to the metal code, know what your doing!
It bugs me to no end to see someone pick up code someone else wrote and start using it without understanding it. Then when things blow up they blame the code they "got" because it
Re: It's not the language, you stupid jackwagons.. (Score:3)
Re:It's not the language, you stupid jackwagons... (Score:4, Informative)
Perl was *made* for text processing. Though it does make handling binary data a bit awkward.
With great power comes great responsibility! (Score:5, Insightful)
Note also another 'language' that would have this same problem, and for which there is no substitute for in the highest-performance applications: assembly language. Yes, Virginia, we still use assembly language in some places, so far as I know. Then you really have to know what you're doing.
Maybe the solution to this problem is to educate and train our programmers more thoroughly and carefully.
Re:With great power comes great responsibility! (Score:5, Insightful)
Flaws in drivers used to be attractive to malicious actors because drivers ran in the kernel and had immense power. Modern operating systems limit drivers so that the damage they can do is greatly reduced. Also helps with stability because your sound card driver crashing won't bring the whole machine down any more.
That's the key to security. Assume stuff will have bugs, isolate it, sandbox it, put layers of security in and limit the damage. A bug in the network stack should at worst crash the network stack, which while annoying is far less critical than being able to read parts of kernel or process memory.
Re: (Score:3)
Re:With great power comes great responsibility! (Score:4, Insightful)
Assuming a halfway decent compiler, you could write a graphics driver or a kernel in Rust with little or no performance penalty versus C. You could probably write one in Go. Many have been written in Ada. And I could name many other languages along the same lines. Those are languages that compile down to machine code and can do static allocation and/or explicit dynamic memory management... with static compile-time type checking and pointer and array safety guaranteed.
Yes, array bounds checks are expensive. However, not that many lines of code actually need to index arrays directly, and especially not with random access as opposed to traversing the whole thing (which can usually be sped up). There are even fewer such cases where the code is on the performance path AND your compiler can't prove what you're doing is safe. And arbitrary pointer arithmetic is still less often needed.
If you have to do truly unsafe stuff all the time to get performance, you've misdesigned your language, your libraries, your RTS, and/or your data structures.
In a sanely designed system, on the rare occasions when you really do need to do something unsafe, you either break into another language (yes, even assembly and maybe even C), or you use some specialized construct that explicitly marks the code as unsafe. But maybe one line of code in 100, or even one line in 1000, uses anything potentially dangerous, and you and your tools can easily identify which code it is.
What you do not do is what C does: have every single line of code potentially full of pointer arithmetic, with the very most common idioms being completely unsafe, not even a concept of a distinction between safe and unsafe constructs, and no protection whatsoever against out of bounds access.
C's whole approach to pointers, unions, arrays, and most structures is obsolete and basically broken.
No, it is not necessary to have that kind of power on every line in your main implementation language.
Hi, there. I've been programming since about 45 years ago, or over 35 if you only count truly professional coding in institutional settings. I haven't always been pounding out code day in and day out during all that time, but I've written many thousands of lines of code in C and assembly as well as various other languages. I have written drivers from scratch for more than one kernel. I have coded on bare metal with no OS at all.
I have coded without a safety net. I coded back when compilers in general were really dumb. They rarely noticed when you'd done something obviously idiotic. They never told you you hadn't checked something you should. They almost never optimized out a check you didn't need to make. They offered you few ways to give them any hints about what you were really trying to do. Sometimes they forced you to do dangerous things just because they generated such bad code.
I have a real CS degree from a top university. I don't tend to take a lot of industry training, because it's mostly crap, but I've been around enough to take a fair amount of it in absolute terms.
I know all the defensive coding tricks. I seem to have a relatively low bug rate compared to many other coders.
I think I qualify as an "educated programmer".
One of the things I've learned from that education and experience is not to expose myself to risks I don't need to take.
For example, if asked to write a large security-critical system, I'm not wet enough behind the ears to actively choose to stick it all in a single address space and then write the bulk of it in C.
That's because my education and training have taught me that all humans, including but not limited to myself, are unreliable components.
It's stupid to put faith in them when you don't have to.
Python, by the way, is not "clever". It has
Re: (Score:3)
Re: (Score:3)
You can write an OS in any language. There are actually a few OSes written in Java ...
So we have compiler languages like C/C++ that require you to actually be a competent programmer who can write code with proper error checking and error handling. ... you know nothing about programming.
Error checking etc. is the same in any language
assembly language. Yes, Virginia, we still use assembly language in some places, so far as I know. Then you really have to know what you're doing.
You need to know what you are do
Re: (Score:3)
There's at least one platform where you need to use a pointer to a specific point in memory. Perhaps some old programmer may remember "char far *video_buffer = 0xA000:0000" from Borland C when doing basic graphics. Here, the compiler can't tell if you're going out of bounds, since it doesn't automatically know what you're doing.
Same applies to modern C. There may be the odd situation where you access memory directly (e.g. some memo
And the news about buffer overflows is... (Score:5, Funny)
that they exist?
This is news in 2018? (Score:2, Insightful)
Unless you just woke up from a coma from 1993, you should have known about unsafe memory practices in 2018.
Switching to a new language like Rust might help this problem, but it ignores the enormous cost of re-writing software, library compatibility, retraining, etc. The security of the language is just one aspect of selecting the language, not the only one.
And it's not as if you get a magic security shield just because you chose a memory safe language. There's plenty of other security problems that are ei
Too much freedom (Score:2)
What TFA is arguing for is a layer of verifications performed by the program's execution environment, checking its every move.
The checks aren't free — they make everything a little slower and/or consuming more resources (such as RAM). Whether that slow-down is worth the increased safety may be subject to debate...
But the parallels with human lives are inescapable. The checks argued for are no different from the much-denounced police practices, such as "stop-and-frisk" [aclu.org], tracking citizens' identificatio [papersplease.org]
Re:Too much freedom (Score:4, Interesting)
Re: (Score:3)
There is nothing in the Constitution against tracking your car's movements on a public road [aclu.org] either.
But I'm not talking about rights per se, but about whether or not such surveillance make sense at all. That is, whether the costs (the time and money, leaving the morals aside) of it justify the benefits.
Quote From The Article (Score:5, Insightful)
"Finally, we can shift the culture around security within software engineering. When I first learned C++ in college, it was expected that sometimes your program would crash."
A quote from the article...WTF school is teaching this kind of crap. It would appear that the issue mainly resolves around the teaching practices and not so much the language.
Re: (Score:3)
Re:Quote From The Article (Score:4, Informative)
The question is who expected this. Certainly not any professior worth anything.
I was taught that not only compiler errors, but also all compiler warnings need to be resolved before the code is considered finished. If I had submitted a program that sometimes crashes, my prof would've asked me if I had slept through his class or if I wrote that shit while drunk.
Re: (Score:3, Insightful)
Yes, because it's written wrong. Now learn how to do it correctly. The original problems this article addresses are not a learning experience environment set of problems.
Get good developers if you need C/C++ (Score:4, Insightful)
Bad developers can create security exploit in whatever is the language of their choice. Sure, with C/C++ you need to be more careful/experienced because they allow this particular type of bug, but in general where C is used it is possibly for a reason and you can't start talking about Java/Python etc (but maybe Rust?), which might be "safer" for a less good programmer.
Re: (Score:3)
C++ programmers think of themselves as elite.
That is not what I see. I see more programmers who choose to NOT use C++, but know it... than C++ programmers who are good at something (a modern language) other than C++.
Rust is safer for ANY programmer, just as Java and Python are. Rust just does not do performance trade offs as the others do for that safety and instead pays with a steeper learning curve.
None of the C++ programmers talking about Rust seem to have learnt it. If you are so elite, learn it in a we
Not a buffer overflow (Score:5, Insightful)
What the author describes is not a buffer overflow. Article is ill-informed click-bait.
Re: (Score:3)
FTA: (disclosure: Rust’s primary sponsor is my employer, Mozilla)
Given Firefox's continued problems with memory management over time, I can start to get some understanding as to why, if the guy really thinks an out-of-bounds read is a buffer overflow.
Re: (Score:3)
Firefox in Rust today is doing a lot better than Chrome in C++ today, especially with regards to memory consumption.
There should not be any significant differences in memory consumption between Rust and C++, as per design since the compilers emit similar instructions.
https://benchmarksgame-team.pa... [debian.net]
Is the article crap or just the summary? (Score:5, Informative)
I decided not to read the article when I saw the following:
Sometimes this will result in a crash, but in many cases you get whatever happens to be at that location in memory, even if that portion of memory has nothing to do with our list. This type of vulnerability is called a "buffer-overflow,"
That is not a buffer overflow. That is an out of bounds access, which a completely different type of vulnerability.
Sometimes, this specific access violation is called a buffer over-read, but anyone calling it a buffer overflow is simply sloppy or wrong---neither of which makes me interested in reading their material.
Re: (Score:3)
This. My first thought upon reading the summary: "Here's a person clearly not understanding what they are writing about, but asking me to follow their advise about safe programming... riiiiiight."
Ad for Rust (author's employer) and Swift (Score:4, Insightful)
When did I first hear about "Buffer Overflow" which seems to be the bug in the author's bonnet? Oh yeah, about 35 years ago when I first started programming in C.
When I RFTA I was floored by the statement "When I first learned C++ in college, it was expected that sometimes your program would crash." - the author implies that it just happens but that's never been true and I would really be hesitant about hiring a programmer that accepted that his programs sometimes crash.
He doesn't like C/C++, good for him, but programming in Rust or Swift won't help the security problems out there now or in the future.
Re: (Score:3)
"When I first learned C++ in college, it was expected that sometimes your program would crash." - the author implies that it just happens but that's never been true and I would really be hesitant about hiring a programmer that accepted that his programs sometimes crash.
...welcome to the Java mindset?
(/me ducks and runs, laughing maniacally...)
Re: (Score:3)
Re: (Score:3)
Re: (Score:3)
C? you newbies (Score:3)
I achieved this overflow with FORTRAN on a DEC PDP 11/70 back around 1974. My whole college ran on the one machine, and occasionally the overflow would feed me cool stuff like chunks of grade reports.
python cant solve all the problems. (Score:2)
Article is longer than the clickbait title (Score:3)
Apparently this article is long enough to actually address all the points everyone here is bringing up as a counter-argument.
Of course its also pushing Rust, which nearly all these articles do.
While I personally have no real opinions or experience with Rust, I don't yet see it being used very much. It mostly seems to be used for novel standalone utilities, which are not parts of larger projects.
Re: (Score:3)
Ah, the Rust fuckups are at it again. That explains it. They do not understand what makes code insecure.
Re: (Score:3)
I know its supposed to be used for that. I also know that its proponents are screaming at everyone to find every opportunity to use it for that.
What I haven't yet noticed, is actually seeing a meaningful swath of said core libraries actually get rewritten in Rust.
A large of it is due to the popularity ... (Score:2)
Mozilla and Rust (Score:5, Interesting)
The article is a Mozilla developer trying to push people onto Rust. And while Rust is great for *SOME THINGS*, it is still a new language that falls far too short on too many others. I've recently attempted to build some demo programs in Rust, and had not enjoyed the experience one bit. A simple "hello world" application written in Rust and compiled generates a binary that is in the order of ~500-1000KiB in size. Now, let's put this into a little bit of perspective of where I personally use C/C++ these days. I work with microcontrollers as a hobby, one of which has a total of 8KiB flash ROM. But this is just one example. Now, imagine writing an entire operating system in Rust with that type of file size. How many tiny utilities combined make up Linux or FreeBSD? Just imagine if literally EVERY single utility bundled with the OS was half megabyte in size? There are thousands of utilities, which would lead to OS bloat to an unimaginable level. Rust is promising for sure, and is doing great things for Webrender at Mozilla, but it just isn't there for smaller applications at all.
More Rust propagnda (Score:3)
All the way down. (Score:3)
But at the end of the day, people have been aware of buffer overflow problems for what, 60 years now? And there have been solutions for them nearly as long. But when cycles are dollars, those solutions are always expensive, which is why unsafe C/C++ code is still so common.
Python or Java Couldn't Exist w/o C/C++ (Score:5, Insightful)
It is impossible for those languages with "safe" memory access to exist without underlying languages that can openly access memory and that don't hide the truth of the machine beneath them. It is impossible to build an operating system in Java or Python -- they are made-up realities. They are designed to make computer pretend to work in ways they actually don't... in ways humans find easier to view and work with programming logic.
C and C++ do not hide the underlying machine because they are made to build the layers that actually allow software to work with the machine. The machine is instruction sequences in memory that manipulate memory -- memory is a singular long sequence of bytes. At the lowest level in any computer, that's what's there. Definitely not Python or Java. Python and Java must be written in either assembly language or a "true to the machine" language like C or C++. I am quite sure without checking that they are both written in C++. In fact C was specifically created to write the first UNIX... It's core is the core of POSIX of which even Windows shares... as DOS was written in C.
It's truly absurd to blame C and C++ memory unsafety. This illustrates a lack of fundamental understand of how computers work.
C++ compilers should have a "safe" mode (Score:5, Insightful)
C++ is really two languages in one: backwards-compatible C and modern C++, and unfortunately there's nothing to stop programmers from inappropriately using low level C features when safer C++ alternatives (smart pointers, STL data structures) would be a better choice.
The C++ standards body should define a "safe-C++" subset that doesn't allow legacy features like C-style arrays and raw pointers. The compilers could have an option to enforce safe mode and only allow exceptions in sections of code explicity marked as unsafe (#pragma unsafe ?).
Re: (Score:3)
K&R (Score:4, Funny)
I donâ(TM)t know why K&R rewrote Unix in C; it was a far more stable and secure operating system in the original JavaScript.
Enter Modern C++ (Score:4, Interesting)
So I'm a long time C++ Dev, but have been trying to wrap my head around modern C++ (2011 to current) and it seems that there are a lot of improvements that would avoid those kinds of errors.
Unfortunately I observed that C++ is becoming less about writing your program and more about telling the compiler how to build it. It's also filled will all kinds of new acronyms, like SFINAE and CTAD, and new concepts like costexpr.
But I think it's all too little too late. Check out this "simple" map():
std::vector originals { 1,2,3};
std::vector triples;
std::transform(originals.begin(), originals.end(), std::back_inserter(triples), [](int item){ return item*3; });
Who wants to write that code? How does that code convey the intent to the user? You know it's doing a map because I told you. But that code was written for a compiler, not a human to understand.
Re: (Score:3)
No, not really. What sucks is having to learn the many quirks of modern C++. Any language has quirks, but none has as many as C++. And I thought Javascript was a piece of garbage... enter C++.
And the solution? (Score:4, Insightful)
C doesn't have seat belts. (Score:3)
Sorry, but Not A OOP Fan. (Score:3)
Can we please stop this nonsense? (Score:3)
The problem is not C or C++. The problem is incompetent developers. They manage just fine to make things in other languages just as insecure.
Re: (Score:3)
C is Assembler 2.0 ... (Score:3)
... and C++ is Assembler 3.0. Ignore this and you'll always write software that introduces these bad heavy impact bugs at low level. Get off your high horse however and pull that stick out of your ass and stop banking on "we've been doing C for 30 years now and I'm not having some young whippersnapper tell me what's what" and you'll actually learn some really useful stuff. Like Ocaml, Rust or Eiffel and be amazed at how productive you can be and how sound the quality of your output is based on the PL you're using.
To quote demotivator on this: "Tradition - just because you've always done it this way doesn't mean it's not incredibly stupid."
My 2 cents.
Not a problem with C/C++ but a human problem (Score:3)
C language is well known and has no inherent problem. it's behaviour is well documented and you get what you program with it... nothing less, nothing more.
If you use something like while(*a++=*b++); it's at your own risk... The only assurance that C gives you is that the assembler code that'll be generated will exactly do what you asked.
Problem is manyfold :
1) many people don't care about low level anymore
We have a plethora of "high level languages" which hide what is done beneath. Too many programmers don't know what's happening under the hood (well, with some langages, it's nearly impossible due to some level of secrecy about the inner working).
Thinking about the potential consequences of a line of code is becoming quite difficult...
2) CS teaching is not enough centered about secure practice
This is linked to a problem that affect the whole teaching system : teachers usually don't use their knowledge in "real" situation. Far too many teachers ended up as teacher after university without ever working in their study domain. They only have an academic knowledge and as result, they often forget about the security good-practice and such (disclaimer : I'm CS-teacher... but I also worked as programmer before... and I see the above problem with many of my coworkers, not only CS-Teachers)
3) Management usually push for quick and dirty coding ... everything that is not visible... The thing may even be aggravated when the management is computer illiterate and unable to understand the issues...
Too many management forget about the security aspect : the program must be ready as fast as possible, putting aside optimisation, security checking and other,
The management has usually zero-liability for problem arising from program they supervised... so they have no incentive for such a long term investment... If the program is out quickly, they'll most likely get bigger bonuses and that's their only focus...
4) High level languages hide incompetence ...) than using a lower level one (ASM, C, C++, ...) No need to care about memory allocation, bound checking, ... and many errors will trigger an exception and can be hidden.
It's way easier to make a runnable program using high level "script" languages (PHP, Python, C#,
This won't make the program any better... It'll just hide the mistakes... And having something running will too often be enough for the management who don't care to have a look under the hook. I saw my share of awful code done by an incompetent coworker... But with some small-talk and such he used to be able to make it "pass"... he attributed the slowlessness to external factors and until I arrived and had a look at his code, there was nobody who could point the issues...
And I could go on...
Basically, if the program is broken, it's not the langage's fault but the programmer's fault (and often the manager's because he didn't request an high security level). The problem was minor for a long time, because the computers were not connected 24/7... but now, such an error may have devastating results (remind the Nimda worm which exploited an IIS buffer overflow... and infected all exposed IIS in less than 24 hours ?)
Better training about securing the code during CS school (and after) and making managers liable for big security problems could help to limit the problem...
Re: No problems with my first post algorithm (Score:5, Funny)
Shows how optimized your code is. Didnt even make first post.
He forgot to check clock()
Not overblown (Score:5, Interesting)
C/C++ are important for some things. Experienced developers know exactly when and how they should be used
A) Experienced developers do not always use them in appropriate circumstances
B) Not all programming is done by experienced programmers
C) One doesn't get to be an experienced programmer with C/C++ without working with the tools and making a lot of mistakes.
D) Experienced programmers still generate bugs and security holes
E) Tools that require the programmer to catch 100% of a known problem with known solutions are bad tools
F) This problem with C and C++ has been known about and routinely ignored for decades.
G) It is screamingly clear that training will not resolve this problem as a general proposition
We have a bunch of sloppy code, written in a hurry, often by programmers who didn't know what they were doing, built over decades with tools which allow sloppy coding practices to occur. Sure there are occasionally reasons to work without the safety net but these are the exceptions that should prove the rule.
Re:Not overblown (Score:5, Interesting)
You do realize that you could pretty much replace "C/C++" with any language that has that level of access, usability, and flexibility, right?
Re: (Score:3, Interesting)
This is why I love languages that can compile or otherwise mesh together. Use C/C++ for the places where the flexibility and access really pay off, and then switch to more restricted languages by default for most tasks.
Re:Not overblown (Score:5, Insightful)
What exactly is it Ada can't do but C/C++ can?
Re: (Score:3)
Not require an i7 to run like you have a 386.
Re:Not overblown (Score:5, Informative)
The modern Ada compilers actually produce fairly streamlined code. While you might think that there would be an overhead penalty for having to range-check every array access, the reality is that the compiler will remove the range check if it can prove that all of the indices used are within bounds. If you are writing good Ada code (rather than trying to convert your C coding paradigms to Ada), the compiler can actually make this proof most of the time. If you add SPARK to Ada, it will force you to write always-provable code.
I program in C/C++, Ada, and assembly, and I actually enjoy programming in Ada the best out of those three. I did not feel that way when I started learning the language, but I find my own personal error rate is so much lower in Ada (eg. once it compiles, it actually does what I want the very first time) because the compiler will catch many simple errors. I also find my code is significantly easier to read a year later when I need to revisit it to make some modifications.
Re: (Score:3)
I believe it was Tony Hoare who opined, back in the late Jurassic Period, that running with checks enabled during checkout and turning them off for production was akin to wearing your life jacket in the harbor and then taking it off when you ventured out to open ocean.
While SOME people do in fact learn, as you suggest, not all of them do. I saw too much sloppiness in production code at Nortel Networks - I can say that because the company is now dead and gone - to be optimistic about people's ability to lea
Re: (Score:3)
Most of the time, any decent non-C natively compiled language is better than C, except for a small set of cases that have a small enough to be humanly manageable codebase that cannot absolutely afford to make any performance compromises.
It isn't that C does not have a place. It does. It just should not be used as the default systems language.
If you are not willing to place a lot of resources into verifying C/C++ code, the marginal performance penalty imposed by safer, yet still natively compiled languages i
Re:Not overblown (Score:4, Interesting)
There is a an important key point here, any language that can do what C/C++ do will have those same problems
This is not necessarily true. There are times when you want an unbounded pointer that can access any arbitrary address, but in C, pointers are unbounded by default. It would be safer to require a specific keyword to create an unbounded pointer, so it is clear to both the writer and the reader that it is intentional. This would lead to safer code, with no decrease in capability.
Re: (Score:3)
I'm not a trans otherkin. How can I possibly use that language?
Re: (Score:3)
I'm intrigued, but waiting for it to stabilize. A language that can't compile code written three years ago is no kind of language for any serious task.
Re:Wrong tool for the job (Score:5, Interesting)
C/C++ is not a language.
C cannot be made safe. It's a language for when you really need raw access. It's a language for kernels, and for writing languages. It's a language for when a memory address actually represents a temperature sensor (if you've ever wondered what a "const volatile int" was). People definitely use it beyond those bounds.
Heck, it's just tradition that keeps kernels in C. Very little of a kernel needs to be.
C++ can be used in a very safe way. All the libraries support it. The continuing problem is that people don't do that. They write "C/C++", that is, they write C++ as if they were writing C. The fact you can do that may make C++ irredeemable for security-conscious code.
I find that very frustrating, having written C++ for years without a memory leak or buffer overflow (it's easy if you use the right primitives). But it would be very hard to police junior coders and keep such vulnerabilities from creeping in, and I wouldn't start a new project in C++ if security was any concern.
At least with C you know where you stand, and that if security is paramount you need to minimize it to where it's the right tool, review it heavily, fuzz test it, and so on.
Re:Not overblown (Score:5, Insightful)
____1) Experienced programmers are expensive.
Re: (Score:3, Insightful)
Re: (Score:3)
Re: Not overblown (Score:4, Informative)
Re: (Score:3)
In general, it is nearly impossible to explain to your boss that your Proof of Concept, isn't the final program.
Re: (Score:3)
Re: (Score:3)
If everyone did everything perfectly all the time there would never be any problems.
The solution to everything.
Re:Overblown (Score:4, Interesting)
So you are making the Fast Food Argument.
Sure...it's bad for you...might even kill you.
But it's quick and it's tasty!
Re:Overblown (Score:5, Insightful)
I hate this argument and always have. By straight raw number comparison yes C/C++ are faster than most managed languages. Problem is most of the zealots that parrot that don't bother to tell you it is typically only a few milliseconds, often nanoseconds, faster on the general operations (hell there are instances where is is actually slower, though admittedly not as many, Dictionaries are a great example). Even in compound highly abstracted layers of code you might see a 5 to 10 ms difference on the operation if you can manage an apples to apples comparison (which typically you can't unless it is a very trivial operation because the coding style between C/C++ is vastly different than even C#) for a very compute intensive algorithm. Even then, the main reason the execution speed is better at all is because the C++ optimizer is significantly better and more mature than a lot of other languages. As we have seen more improvements to the compilers and optimizers of other languages the gap has closed (even Java and C# are surprisingly fast these days with their respective JITs).
Even theoretically, the performance hit you're referring to is merely a constant added onto the performance calculations because they are able to perform checks based on memory allocation of the heap in managed languages. Hell, it isn't even a great comparison because C/C++ has to perform scope checks to ensure certain objects are even supposed to be accessing the memory in question that is already allocated to that process. Access violations can still occur in those languages.
At the end of the day very few users can tell much of a difference between a managed and unmanaged language's program, but error rates are way higher in the unmanaged languages (some of it is general unfamiliarity and learning curve of the language, but even experienced developers will still have higher rates from what I've seen). For general use, I dislike C/C++ for writing programs because of the maintenance factor and how many "roll my own" algorithms that can be required, but I will completely agree it does still have solid and semi-common use cases (embedded systems are ruled by those languages and probably will be for a long time). For me, it comes down to using the right tool for the job, and for a lot of business solutions, a managed language is just more suited to doing the work.
A few milliseconds is forever in computer time (Score:5, Insightful)
I hate to break it to you but 5 to 10 ms is a huge amount of time when you are dealing with big data. Try sorting a 1 billion row table when each row takes a whole millisecond to get in order. That's a million seconds! For the math challenged out there it is nearly 300 hours!
Re:Touch a Nerve or Something? (Score:5, Interesting)
Re: (Score:3)
In C++ land, every programmer is a bad programmer.
We are not talking about a college student who learnt C++ last year, who has yet to learn good practices and common sense.
Nearly every C++ bug that makes the news was from high profile projects, written by well-paid and highly experienced programmers. And yet, these blunders are common place.
At some point, one has to conclude that the tool isn't designed according to natural human limitations of otherwise intelligent people.