Timur Doumler: C++ and Safety

Organisations such as the National Security Angency (NSA) and the National Institute of Standards and Techology (NIST) are currently urging developers to move away from programming languages that are not memory safe. C++ is arguably not a "safe" programming language in its current form. Why is that? And should we do anything about it? If yes, what, and how? Have we arrived at a crossroads for the future evolution of C++? What does "safety" even mean, and how is it different from "security" and "correctness"?
In this talk, we attempt to give useful definitions for these terms. For safety in particular, we can distinguish between functional safety and language safety, and identify different aspects of language safety (of which memory safety is one). We discuss how and why C++ is considered "unsafe" and what consequences follow from that for different domains and use cases. We look at how other programming languages, such as Java, Rust, and Val avoid such safety issues, what tradeoffs are involved in these strategies, and why we can't easily adopt any of them for C++. We consider the tooling available today to mitigate safety issues in C++, such as sanitisers and static analysers, and their limitations. Finally, we look at the future evolution of C++ and discuss the current work on C++ Contracts and other recent proposals targeted at making C++ more safe.
This is the rehearsal of Timour talk given at StockholmCpp Meeetup 0x27
www.meetup.com/stockholmcpp/e...
The event was kindly hosted by NetInsight AB
netinsight.net
More information about C++ user groups in Sweden
www.swedencpp.se

[@russCoding]

Thank you Timur Doumler for your video; this topic has been troubling me for some time. The reports which draw conclusions by summarily identifying C and C++ as the same language cannot by this fact alone draw accurate, insightful and valuable conclusions. This approach lacks an understanding of the very core differences between C and modern C++ and why they are so very different. It is understandably difficult to perform studies on vulnerabilities and the direct impact that memory safety has on it, and then go on to attribute any singular bug-causing vulnerability instance to either C or C++; simply due to the fact that almost all C code can be compiled within a C++ compiler due to backwards compatibility. However, most of these instances are either written in C or C++, but not both. It is possible to distill the instances and attribute them to either C or C++, but simply this is not the course followed due to the time cost on the researchers, and the alternative of simply generalizing them as the same language is too convenient. Working in the information security field and as security researcher myself, I am largely disappointed in the NSA report and the approach they took when compiling their report. Having said that, it wouldn’t be the first time that the NSA disappointed both myself and the general security field in general. Typically, security researchers are not C++ experts and are more familiar with programming in C, and at the same time are opponents against C++; either due to the length of time and required knowledge to understand the language (and situations where UB can occur), or simply because they see C++ as convoluted when compared to their ‘pure’ C language. Of course, there are outliers in the field who want to evaluate everything based on merit, but in my experience in the field, this is simply not the vast majority. The general recommendation by the NSA report simply suggests to discard both languages, and use the new thing; completely disregarding any safety mechanisms that C++ has evolved over the last 38 years. Do we want to simply ‘throw the baby out with the bath water’ based on the unjustified and ill-formed summary by individuals who are not C++ experts? It is irresponsible for organizations such as the NSA to make generalized recommendations about programming languages without having understood the details such as in the case between C and C++, and also not to provide that distinction within their reports.

[@peterkochlarsen2792]

Interesting and nuanced talk definitely worth watching. Thank you Timur and SwedenCpp

[@farhangamary]

Great video. I however think that Safety depends ( mostly if not 100%) on the programmer; In C++, the coder has much more freedom; It is not and advantage over C++ if a programming language restrict the coder just in purpose of safe coding.

[@dariuszantoniuk]

Typical for a C++ talk there's plenty of misconceptions about how Rust works: * you can write a linked list in Rust, it will simply be dynamically checked to follow the rules instead of a static check * you can have multiple references capable of mutation with a dynamic check to make sure they don't occur at the same time * the fact that rust provides thread safety wasn't mentioned at all, but rust does prevent data races, which almost none of the other languages do * with static approaches rust doesn't need to tradeoff between safety and performance, but the presentation says these are inevitable - C++'s type system is just too old and weak to take advantage of these * all the arguments C++ people badgered C people with to switch to C++ apply to switching from C++ to Rust. If you used these arguments but you forgot them now, you're a hypocrite. I was one of those people that advocated for switching to C++ for the better type system, now I advocate for switching to an even better one in Rust. One refreshing thing about this talk is that the author is at least partially capable of admitting that reducing the scope of the problem is better than not doing anything (something which most C++ people including Bjarne aren't capable of). But then he goes on to say that you'd need to rewrite your entire stack in rust, as if just writing new code in rust is insufficient. Improvements are good.

[@HaraldAchitz]

This talk was about C++, its (possible) future, and not at all about Rust. To contribute value, check all the Rust talks that get details about C++ wrong. This would give you enough to do to let this channel alone with your Rust spam ;-) Your 5th point is, btw, wrong, since that is technically a different situation. I'll let your self find out why, but give you a keyword as a hint: Interoperability.

[@CuriousCauliflowerX]

​@@HaraldAchitz This talks has mentioned rust at least 5 times, it'd be nice for it to be accurate. Rust is perfectly interoperable with C just like C++ is, you can call it from C, C can be called from Rust. What is not interoperable is C++ and it's toxic type system which nobody can interoperate with unless they're willing to embed clang. C++ has a myriad of interiop issues that Rust doesn't, for example the static constructor initialization bullshit that you have to deal with whenever you need to initialize a C++ runtime. To the point, where MSVC people recommend against using C++ in DLLs. That makes C++ barely able to interoperate even with itself.