[DCKing]

There are many reasons why curl uses C, and should continue to do so. Yes, C allows a combination of portability, performance, and accessibility of your source code by others that is not matched by any language. And yes, C was a perfectly valid choice throughout the vast majority of its life and still is. Switching is not a realistic option at all.

But I think Daniel's original attempt at explaining away C's security issues has been debunked. And I think he owns it well by singing a slightly different tune in this blogpost.

The lesson learnt here is that if you use C, don't try to explain away the security issues you have just opened for yourself. It will not hold up. Accept that the safety of C is a very serious issue, and that there are other reasons you choose it. Choosing C over more secure options does not mean you don't care about security, but it means that you had to make pragmatic choices. 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.

[fiedzia]

Well said.

[generic_user]

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

[DCKing]

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]

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]

Coverity is a static analyzer, and it can detect bugs in code that is not run.

[generic_user]

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.

[DCKing]

We've gone from arguing "the security issues for C are overrated" to now arguing either "security issues don't have solutions I like" or "real programmers should be able to deal with these things" (I'm not sure which).

In addition, you're arguing a strawman. Nobody says that direct memory access should be taken away permanently. Many 'safe' languages allow you to directly access memory when you need it.

> A computer is a tool for computation not an adult diaper designed to prevent leaks.

This attitude is why we can't have nice things. It would be great if you cared more about the security and safety of the things you make than whether you look cool while making them.

[generic_user]

> We've gone from arguing "the security issues for C are overrated" to now arguing either "security issues don't have solutions I like" or "real programmers should be able to deal with these things" (I'm not sure which).

I don't think anyone was arguing any of those points. What was being explained is that C/C++ is designed to be flexible and simple and it was know from its inception that that flexibility lets the programmer 'shoot them selves in the foot'. Building out tooling to address any error patters in usage and keeping that basic simplicity and flexibility is desirable. More desirable then moving to a more complicated less flexible language that may eliminate some possible errors.

There are literally millions of C/C++ programmers and projects writing secure reliable code. Picking out a few open source projects and turning there bug reports into an internet drama is not going to convince anyone the sky is falling.

> In addition, you're arguing a strawman. Nobody says that direct memory access should be taken away permanently.

I think its fairly clear that the sentiment was.

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

This has been the justification for every misguided attempt to 'make things better' for a very long time.

A short list of unnecessary things that needed to be stopped thought the years. * Pointers * Manual memory management * Unconditional Jumps * direct access to machine words ie bytes * assembly instructions. etc..

I am fairly skeptical of arguments that suggest 'the programmer does not need that'.

[DCKing]

> There are literally millions of C/C++ programmers and projects writing secure reliable code.

I believe that there are millions of C/C++ programmers that think they are writing secure reliable code. But these there is an overwhelming amount of evidence that they don't and (for C at least) can't. There is plenty of evidence that at least C does not give you the proper tools to actually write safe code outside of trivial programs in the first place. (I cannot speak for C++)

You're still arguing a strawman. Nobody wants to take away your pointers, manual memory management, unconditional jumps or assembly, and nobody is suggesting that you don't need them. People just want to make it easier to use them responsibly without making the mistakes everybody keeps on making all the time.

[klibertp]

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

Oh, so you say they don't use C, right? It's defined in terms of abstract machine which has very little in common with how actual hardware works nowadays...

[qznc]

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.

[wott]

Most of those safety mechanisms are actually implemented in C.

Just saying :-)

[generic_user]

A game engine is not a school bus.

[pjmlp]

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.

[Filligree]

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

[jerf]

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

[pjmlp]

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.

[sanxiyn]

Well, Facebook Infer is open source, but many are not running even that!

http://fbinfer.com/

[generic_user]

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]

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.

[viraptor]

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

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]

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