4 ms·

> Choosing C over more secure options and subsequently attempt to minimize the security impact of this decision (not talking about Daniel here) will lead you to

> Choosing C over more secure options and subsequently attempt to minimize the security impact of this decision (not talking about Daniel here) will lead you to not addressing those issues effectively. When you start a new C/C++ project in 2017 you can effectively and confidently address security and 'safety'. And it is done on a regular basis. There is an entire infrastructure of tools and introspection refined over the past 30+ years for C/C++ that is part of the project from the beginning. Address sanitizes, Better compilers, Valgrind, Intel's tools etc. All of the potential problems are known and there are tools to deal with them. But the responsibility is put in the hands of the programmer like many other things in C/C++.

pjmlp 10y ago
CppCon 2015 as Herb Sutter asked the audience how many use regularly any form of static analysis tools, the answer was around 1% of the audience. The video is easy to find if you want to watch it. So apparently the tools might be there, but they are ignored by those that should be using them in first place.
- generic_user 10y ago
  That's a fair point. And for a large portion of software the benefits of C/C++ do not outweigh the potential costs and code should be written in a more protective language. But that does not change the fact that C/C++ is preferable and often the best choice in certain domains.
  - pjmlp 10y ago
    I don't put C and C++ on the same bag, even though you can write C like code in C++. While one might not be able to pay for tools for static analysis, there is no excuse to ignore the type safety improvements C++ has over C. Anyone that writes C with C++ compiler, should keep using a C compiler if he/she wants to stay in the past.
- Filligree 10y ago
  Many of those tools cost money, where we're used to programming tools being gratis. Probably a lot of it is simply lack of familiarity, though. I've never seen a university course that even touches on this...
  - pjmlp 10y ago
    This current FOSS generation is used to tools being gratis, but want to get payed for their work. I always had to pay for my tools, just like any other professional. And I still do pay for the tools I think are worthwhile, if not upfront, at least as donation.
  - jerf 10y ago
    Developers, on average, don't even use the free tools. I mean, speaking as one of the 1% who fully voluntarily uses these sorts of tools (and can generally only get free ones either because the price is prohibitive for the expensive ones, or I'm working in languages that expensive ones don't exist for), I think you're all bloody loonies for not doing it too. Offload to the tools everything you can, to save your precious brain cycles for the stuff that matters. Makes you look like even more of a hero. (The excuse I see all too often that by doing that you'll atrophy your own judgment is, by the way, itself just proof you've never used these tools, or at least not used them properly. If you use them frequently, i.e., at commit-time, rather than quarterly-release time, they train you by telling you what you did wrong, and you learn how to write better code that meets their criteria fairly quickly. They make you a better programmer. These things should be used early and often; I'm sure a lot of the reasons people tend to not enjoy using them is that they want to write a quarter million lines of code without ever consulting the tool, then run it once at the end. That is a terrible plan. The tool will scream bloody murder and especially in C you are very likely to discover that your entire architecture is fundamentally impossible to fix now, making it very discouraging. Use the tools early and often. Seriously, as soon as you've created the new project and have hello world going, hook up the tools. They both provide more value and are way easier to use that way.)
  - sanxiyn 10y ago
    Well, Facebook Infer is open source, but many are not running even that! http://fbinfer.com/ http://fbinfer.com/
DCKing 10y ago
I do get a vibe of tone deafness coming from such a reply. 1) You're stating that automated tools are a solution in a thread in a blogpost for a heavily scrutinized tool that has a zero tolerance policy for Coverity problems, uses Valgrind and address sanitizers and still owes more than half of its CVE's to various language and memory safety issues. 2) "The responsibility is in the hands of the programmer" - I think we have argued enough that putting this responsibility in the hands of very imperfect programmers is precisely the problem and we should do the best we can to stop it. You're minimizing C's security issues again, please stop doing that.
- zuzun 10y ago
  They can't detect a bug in code you never run. These were problems with the curl API, not the curl command line program.
  - amadvance 10y ago
    Coverity is a static analyzer, and it can detect bugs in code that is not run.
- generic_user 10y ago
  You could make the case that the reason why we have C/C++ and its still in use is because of the tone deafness of academic language designers. Language designers have been arguing (mostly with themselves) since the 1970's that pointers are dangerous and memory management is bad and that programmers should not have those things. We can go on using C/C++ and language designers can go on creating there new version of Pascal. We all know how that turned out. > I think we have argued enough about that putting this responsibility in the hands of very imperfect programmers is precisely the problem and we should do the best we can to stop it. System designers and those writing performance critical code program hardware. Not an abstract machine that the language designer thinks is good enough for lowly programmers. Convince Intel and AMD, Nvidia etc, that they should make chips and instruction sets that have no access to memory, cores, vectors and so forth because 'we should do the best we can to stop it'. Lets see how many of there clients want to buy useless blobs of silicone. A computer is a tool for computation not an adult diaper designed to prevent leaks.
qznc 10y ago
You can also drive your car without ABS, ESC, and other safety mechanisms. The responsibility is put in the hands of the driver. Yes, there are reasons to sometimes disable those mechanisms. Yes, it is not a good idea to force everybody right now to abandon cars without it. Still, if you build a school bus today, I would criticize you, if you don't include the safety technology.
- generic_user 10y ago
  A game engine is not a school bus.
- wott 10y ago
  Most of those safety mechanisms are actually implemented in C. Just saying :-)
viraptor 10y ago
> All of the potential problems are known and there are tools to deal with them. This is untrue. There are tools out there to deal with a lot of the issues, but not all of them. Due to what C allows and the halting problem, you cannot create such tools. Static analysis and dynamic sanitizers are still useful of course, but let's not pretend they're a solution.
stable-point 10y ago
Arguably someone adhering to the C++ Core Guidelines, using GSL and using the new static analysis tools (currently only in VS?) can be reasonably confident about choosing C++ for a new project in 2017.
zerd 10y ago
Show us one of those safe C/C++ projects of a major size. I've never seen one.

pjmlp 10y ago

CppCon 2015 as Herb Sutter asked the audience how many use regularly any form of static analysis tools, the answer was around 1% of the audience. The video is easy to find if you want to watch it. So apparently the tools might be there, but they are ignored by those that should be using them in first place.

generic_user 10y ago
That's a fair point. And for a large portion of software the benefits of C/C++ do not outweigh the potential costs and code should be written in a more protective language. But that does not change the fact that C/C++ is preferable and often the best choice in certain domains.
- pjmlp 10y ago
  I don't put C and C++ on the same bag, even though you can write C like code in C++. While one might not be able to pay for tools for static analysis, there is no excuse to ignore the type safety improvements C++ has over C. Anyone that writes C with C++ compiler, should keep using a C compiler if he/she wants to stay in the past.
Filligree 10y ago
Many of those tools cost money, where we're used to programming tools being gratis. Probably a lot of it is simply lack of familiarity, though. I've never seen a university course that even touches on this...
- pjmlp 10y ago
  This current FOSS generation is used to tools being gratis, but want to get payed for their work. I always had to pay for my tools, just like any other professional. And I still do pay for the tools I think are worthwhile, if not upfront, at least as donation.
- jerf 10y ago
  Developers, on average, don't even use the free tools. I mean, speaking as one of the 1% who fully voluntarily uses these sorts of tools (and can generally only get free ones either because the price is prohibitive for the expensive ones, or I'm working in languages that expensive ones don't exist for), I think you're all bloody loonies for not doing it too. Offload to the tools everything you can, to save your precious brain cycles for the stuff that matters. Makes you look like even more of a hero. (The excuse I see all too often that by doing that you'll atrophy your own judgment is, by the way, itself just proof you've never used these tools, or at least not used them properly. If you use them frequently, i.e., at commit-time, rather than quarterly-release time, they train you by telling you what you did wrong, and you learn how to write better code that meets their criteria fairly quickly. They make you a better programmer. These things should be used early and often; I'm sure a lot of the reasons people tend to not enjoy using them is that they want to write a quarter million lines of code without ever consulting the tool, then run it once at the end. That is a terrible plan. The tool will scream bloody murder and especially in C you are very likely to discover that your entire architecture is fundamentally impossible to fix now, making it very discouraging. Use the tools early and often. Seriously, as soon as you've created the new project and have hello world going, hook up the tools. They both provide more value and are way easier to use that way.)
- sanxiyn 10y ago
  Well, Facebook Infer is open source, but many are not running even that! http://fbinfer.com/ http://fbinfer.com/

DCKing 10y ago

I do get a vibe of tone deafness coming from such a reply. 1) You're stating that automated tools are a solution in a thread in a blogpost for a heavily scrutinized tool that has a zero tolerance policy for Coverity problems, uses Valgrind and address sanitizers and still owes more than half of its CVE's to various language and memory safety issues. 2) "The responsibility is in the hands of the programmer" - I think we have argued enough that putting this responsibility in the hands of very imperfect programmers is precisely the problem and we should do the best we can to stop it. You're minimizing C's security issues again, please stop doing that.

zuzun 10y ago
They can't detect a bug in code you never run. These were problems with the curl API, not the curl command line program.
- amadvance 10y ago
  Coverity is a static analyzer, and it can detect bugs in code that is not run.
generic_user 10y ago
You could make the case that the reason why we have C/C++ and its still in use is because of the tone deafness of academic language designers. Language designers have been arguing (mostly with themselves) since the 1970's that pointers are dangerous and memory management is bad and that programmers should not have those things. We can go on using C/C++ and language designers can go on creating there new version of Pascal. We all know how that turned out. > I think we have argued enough about that putting this responsibility in the hands of very imperfect programmers is precisely the problem and we should do the best we can to stop it. System designers and those writing performance critical code program hardware. Not an abstract machine that the language designer thinks is good enough for lowly programmers. Convince Intel and AMD, Nvidia etc, that they should make chips and instruction sets that have no access to memory, cores, vectors and so forth because 'we should do the best we can to stop it'. Lets see how many of there clients want to buy useless blobs of silicone. A computer is a tool for computation not an adult diaper designed to prevent leaks.

qznc 10y ago

You can also drive your car without ABS, ESC, and other safety mechanisms. The responsibility is put in the hands of the driver. Yes, there are reasons to sometimes disable those mechanisms. Yes, it is not a good idea to force everybody right now to abandon cars without it. Still, if you build a school bus today, I would criticize you, if you don't include the safety technology.

generic_user 10y ago
A game engine is not a school bus.
wott 10y ago
Most of those safety mechanisms are actually implemented in C. Just saying :-)

viraptor 10y ago

> All of the potential problems are known and there are tools to deal with them. This is untrue. There are tools out there to deal with a lot of the issues, but not all of them. Due to what C allows and the halting problem, you cannot create such tools. Static analysis and dynamic sanitizers are still useful of course, but let's not pretend they're a solution.

stable-point 10y ago

Arguably someone adhering to the C++ Core Guidelines, using GSL and using the new static analysis tools (currently only in VS?) can be reasonably confident about choosing C++ for a new project in 2017.

zerd 10y ago

Show us one of those safe C/C++ projects of a major size. I've never seen one.