C++ and Safety - Timur Doumler - C++ on Sea 2023

cpponsea.uk/
---
C++ and Safety - Timur Doumler - C++ on Sea 2023
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.
---
Slides: github.com/philsquared/cppons...
Sponsored By think-cell: www.think-cell.com/en/
---
Timur Doumler
Timur Doumler is the Developer Advocate for C++ tools at JetBrains and co-host of CppCast. He is an active member of the ISO C++ standard committee, where he is currently co-chair of the Contracts study group. As a developer, he worked many years in the audio and music technology industry and co-founded the music tech startup Cradle. Timur is passionate about clean code, good tools, low latency, and the evolution of the C++ language.
---
C++ on Sea is an annual C++ and coding conference, in Folkestone, in the UK.
- Annual C++ on Sea, C++ conference: cpponsea.uk/
- 2023 Program: cpponsea.uk/2023/schedule/
- Twitter: / cpponsea
---
KZbin Videos Filmed, Edited & Optimised by Digital Medium: events.digital-medium.co.uk
#cpp​ #cpponsea​ #cppprogramming

[@olafschluter706]

kzbin.info/www/bejne/n57XoaKZbs-nhac Why is it that the halting problem is so often not understood by software engineers? The theorem states that the halting program is not decidable for every possible program, and proof is given by constructing a rather simple program where one cannot decide whether it halts or not. But that does not mean that the halting problem is undecidable for EVERY program. It is just undecidable for some. For many functions it is easy to give proof that they halt on every possible input.

[@AK-vx4dy]

@21:10 Compiler can have a flag to treat this old constructs as errors or warnings (C# have something like this, wich warns about all bad practices find in a code)

[@gtdcoder]

Most programmers I work with are not even aware of UB or what it is, even the ones using Kotlin and Swift.

[@ABaumstumpf]

You should not mix up multi-dimensional array with pointer-to-pointer-to-pointer - those are NOT!! the same, not even close. Yes arrays can decay into pointers, but that does not make them the same. Example: "int chessboard[8][8];" is a contiguous region of memory - it is guaranteed that this is a singular "8*8*sizeof(int)" chunk of memory and you are allowed to iterate over that with a pointer. but if you try that with pointer-pointer... "int** chessboard = new int*[8]; for(int i = 0; i < 8; i++) chessboard(i)=new int[8];" While this also gives you some memory this will be 1 chunk of "8*sizeof(int*) + 8*( 8*sizeof(int))" - 2 different types and potentially 9 disjoint regions of memory.

[@kevinchadwick8993]

Ada is the best choice by far as it combines ease of use with a higher safety than even Rust provides (logic error avoidance through it's type system).

[@N....]

8:09 more halting problem propaganda. The halting problem does not apply to real world computing because real world computing does not have infinite memory, and a program cannot change its behavior based on the result of the program that is analyzing it without incurring infinite recursion.

[@ABaumstumpf]

Safety... if the comittee was not so royally opposed to the one thing that people have been asking for for decades: Strong Type-aliases. That would help prevent so many problems. Not just does it directly prevent many bugs from being written to begin with, because it would make intent so much clearer and so much easier to create a safe interface. And making it easier to engineer code also means lower mental overhead and thus a better programming experience (which in turn improves code-quality). std::atomic also was a mistake as it is mixing up independent concepts. It not only means operations are atomic (aka can not be observed in a partial state), but also they are volatile (they must be performed) and have memory-ordering. S Often it is claimed that `atomic` variables do not need to be marked volatile: Well that is completely WRONG - the standard makes no guarante about atomic operations not being optimised together. For example `atomic` does not guarantee that a load is actually performed. When dealing with hardware-registers just reading from them can change their value. In this case using a std::atomic would lead to incorrect behaviour. So the standard is mashing together different behaviour-descriptions in a singular keyword instead of making `atomic` a qualifier like it should be.