Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Bug Programming Security

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.

This discussion has been archived. No new comments can be posted.

The Internet Has a Huge C/C++ Problem and Developers Don't Want to Deal With It

Comments Filter:
  • by Terwin ( 412356 ) on Thursday November 15, 2018 @11:47AM (#57649350)

    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).

    • by sjbe ( 173966 ) on Thursday November 15, 2018 @12:11PM (#57649556)

      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.

      • 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.

        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

    • by jythie ( 914043 )
      Unfortunately, this also requires management to be proactive since even if a developer or two are willing to address the shortcomings, if you don't have technical barriers to stop bad behavior you need to use social/process barriers instead. Even saying 'ok, for this project we are using this more secure string/memory/whatever library', you have to keep an eye on everyone so that they use it.
    • by Spinlock_1977 ( 777598 ) <Spinlock_1977@yaho[ ]om ['o.c' in gap]> on Thursday November 15, 2018 @12:27PM (#57649682) Journal

      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?

      • by Tom ( 822 ) on Thursday November 15, 2018 @03:10PM (#57650864) Homepage Journal

        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?

  • by Penguinisto ( 415985 ) on Thursday November 15, 2018 @11:50AM (#57649364) Journal

    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.

    • by Luthair ( 847766 ) on Thursday November 15, 2018 @12:01PM (#57649480)
      What if the 18-wheeler were designed in such a way that it was very awkward and painful to check mirrors....
      • by iamgnat ( 1015755 ) on Thursday November 15, 2018 @12:13PM (#57649564)

        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.

      • 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

        • by Luthair ( 847766 )

          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.

    • 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

      • by networkBoy ( 774728 ) on Thursday November 15, 2018 @12:48PM (#57649850) Journal

        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 $$.

    • 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)

      by account_deleted ( 4530225 ) on Thursday November 15, 2018 @02:40PM (#57650646)
      Comment removed based on user account deletion
      • by Uecker ( 1842596 )

        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.

  • by Rick Schumann ( 4662797 ) on Thursday November 15, 2018 @11:50AM (#57649370) Journal
    Guess what? As clever as Python and Java are, you can't effectively write an entire operating system in them, or a high-performance driver like a graphics card driver in them. You could try, but the result would be bloated and slow and effectively useless. 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. I'm not saying that when you have an entire platoon of programmers all working on parts of the same project (vis-a-vis graphics card driver or OS) that there aren't going to be bugs that crop up, but slapping training wheels onto them isn't necessarily the solution to the problem either.

    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.
    • by AmiMoJo ( 196126 ) on Thursday November 15, 2018 @12:23PM (#57649646) Homepage Journal

      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.

    • by jythie ( 914043 )
      I think the solution would be closer to 'right tool for the job'. The problem with C/C++ is you have to work to make it safe, as opposed to something like Python where you have to work to make it unsafe, at least in terms of the type of vulnerabilities the OP is addressing. I think a lot of the problem comes from C/C++ being used too often for too many types of problems, problems that do not really gain from the amount of control the languages give you but do suffer from needing to take thoughtful explici
    • by Anonymous Coward on Thursday November 15, 2018 @12:56PM (#57649906)

      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.

      Maybe the solution to this problem is to educate and train our programmers more thoroughly and carefully.

      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

    • 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.
      Error checking etc. is the same in any language ... you know nothing about programming.

      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

  • by enriquevagu ( 1026480 ) on Thursday November 15, 2018 @11:51AM (#57649374)

    that they exist?

  • by Anonymous Coward

    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

  • 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)

      by alvinrod ( 889928 ) on Thursday November 15, 2018 @11:59AM (#57649460)
      Sure you can draw parallels, but I don't recall my computer processes having constitutional rights, so excuse me if I don't feel quite the same emotional stir over bounds checking as I might when the police state does something untoward.
      • by mi ( 197448 )

        I don't recall my computer processes having constitutional rights

        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.

  • by deKernel ( 65640 ) on Thursday November 15, 2018 @11:52AM (#57649388)

    "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.

    • I would hope any computer language class would teach about fatal errors [wikipedia.org] when languages are first learned, so that less time would be spent recreating the mistakes of others. Especially if you're teaching the advantages of a high level language. Knowing why and when to pick a specialty language is valuable. Hoping students figure it out themselves isn't.
    • by Tom ( 822 ) on Thursday November 15, 2018 @03:08PM (#57650848) Homepage Journal

      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.

  • by Ecuador ( 740021 ) on Thursday November 15, 2018 @11:53AM (#57649406) Homepage

    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.

    • by jma05 ( 897351 )

      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

  • by thelexx ( 237096 ) on Thursday November 15, 2018 @11:54AM (#57649414)

    What the author describes is not a buffer overflow. Article is ill-informed click-bait.

    • 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.

      • by jma05 ( 897351 )

        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]

  • by EndlessNameless ( 673105 ) on Thursday November 15, 2018 @11:55AM (#57649422)

    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.

    • by Tom ( 822 )

      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."

  • by mykepredko ( 40154 ) on Thursday November 15, 2018 @11:56AM (#57649436) Homepage

    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.

    • "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...)

    • by jythie ( 914043 )
      I don't know, I am not sure I would hire a programer who tried to claim that their programs never crashed when they were a student writing them.
  • by cellocgw ( 617879 ) <cellocgwNO@SPAMgmail.com> on Thursday November 15, 2018 @11:57AM (#57649446) Journal

    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.

  • Lets program the the pic16 in the coffee maker with python.
  • by Octorian ( 14086 ) on Thursday November 15, 2018 @11:59AM (#57649464) Homepage

    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.

    • by gweihir ( 88907 )

      Ah, the Rust fuckups are at it again. That explains it. They do not understand what makes code insecure.

  • ... of C/C++, that creates an outsized number of issues. An even larger part is due to poor programming practices by the developers who write the insecure code.
  • Mozilla and Rust (Score:5, Interesting)

    by darkain ( 749283 ) on Thursday November 15, 2018 @12:07PM (#57649522) Homepage

    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.

  • by 110010001000 ( 697113 ) on Thursday November 15, 2018 @12:09PM (#57649542) Homepage Journal
    I didn't even finish reading the summary, but my guess is this is some sort of Rust millennial who things memory safety doesn't exist in C/C++. Sorry kids: Rust and your boutique languages will not catch on.
  • by jythie ( 914043 ) on Thursday November 15, 2018 @12:11PM (#57649554)
    And what does the poster think those memory safe languages are written in? I can see the argument that C/C++ are overused, and that the jobs people throw them at could probably be done by safer languages without much performance hit.. but then again, you could just use safe libraries within C/C++ and get the same result.

    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.
  • by Slicker ( 102588 ) on Thursday November 15, 2018 @12:17PM (#57649590)

    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.

  • by SpinyNorman ( 33776 ) on Thursday November 15, 2018 @12:20PM (#57649618)

    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 ?).

    • Um, I am pretty sure all compilers have these kinds of flags already. I know Microsoft's had that 10 years ago. GCC has dozens of flags for overflow detection, etc. Rust developers are just ignorant Millenials who think they have discovered something new.
  • K&R (Score:4, Funny)

    by Ukab the Great ( 87152 ) on Thursday November 15, 2018 @12:25PM (#57649662)

    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)

    by scorp1us ( 235526 ) on Thursday November 15, 2018 @12:35PM (#57649750) Journal

    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.

  • And the solution? (Score:4, Insightful)

    by ponraul ( 1233704 ) on Thursday November 15, 2018 @12:36PM (#57649764)
    Rewrite the everything in their favorite/cool 2018 language, instead of using using the newer features of C++ which are designed to mitigate these problems.
  • by Fly Swatter ( 30498 ) on Thursday November 15, 2018 @12:37PM (#57649774) Homepage
    If you are used to a language with seat belts, like java, and you still routinely get ejected, maybe C isn't for you.
  • by BrendaEM ( 871664 ) on Thursday November 15, 2018 @01:06PM (#57649972) Homepage
    I think I understand the value that C++ brings to bringing large groups of people to work on a large project, but a lot of dirt piles up in the little corners.
  • by gweihir ( 88907 ) on Thursday November 15, 2018 @03:21PM (#57650952)

    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.

    • If you genuinely can't understand the design flaws in C and C++ and the costs they have imposed on the industry then you lack experience and insight and you have no place in this discussion.
  • by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Thursday November 15, 2018 @04:15PM (#57651332)

    ... 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.

  • by Vapula ( 14703 ) on Thursday November 15, 2018 @05:58PM (#57652006)

    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
    Too many management forget about the security aspect : the program must be ready as fast as possible, putting aside optimisation, security checking and other, ... everything that is not visible... The thing may even be aggravated when the management is computer illiterate and unable to understand the issues...
    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
    It's way easier to make a runnable program using high level "script" languages (PHP, Python, C#, ...) 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.
    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...

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling

Working...