This feels like a lot of repetitive whataboutism and gas lighting of what people want to address, making C++ more safe in the areas of memory safety. So things like dangling ref/ptr's and out of bounds. There seems to be resistance to talking about how they see these issues being mitigated. It took a fight to get the dangling issue in for loops addressed and seems like perfect is killing good here.
Feds: "Buffins discovered that seatbelts and airbags significantly lower the number of casualties in car accidents. Let's ensure they're included in future models." Cpp: "There's no such thing as completely safe driving on public roads. What we need is training and incentives for responsible driving. Safety features alone won't save every driver, nor prevent all accidents." Feds: "But surely, installing basic safety equipment can't hurt, no?" Cpp: ""Well... we do offer optional seatbelts. On newer models, you can even add bumpers yourself, should you see the need. If you drive an ambulance, for instance, or something similar. But we believe in a tailored approach. Let individuals choose the safety features they find suitable for themselves. Some find seatbelts restrictive and might opt for, say, a louder horn to enhance safety. We could compile a guideline to suggest some of these measures as best practices. Maybe distribute them in public libraries. Feds: "But the numbers look quite good for seatbelts and airbags, specifically. Plus, in our experience we are ignored if we just recommend something instead of making it mandatory by law. Cpp: "...m..mandatory? No, that's not ideal. Mandating airbags would mean people have to fit new steering wheels, which won't accommodate older models. But people expect that they can install the latest steering wheels, always. Also, retrofitting all the older vehicles is not feasible, given their numbers. Plus, the added weight could slightly reduce speed." Feds: "... you might have a point. We've heard complaints about fuel consumption and minor slowdowns in brands that introduced windshields previously, though overall they've become quite popular..." Cpp: "Those aren't suited for low-level driving, you know." Feds: ""Right. But we've come across a new brand that keeps up in acceleration and speed, and includes airbags and seatbelts. It also boasts easier installation of optional parts. Much simpler than your CBrake system, apparently." Cpp: "Ah, of course! 'Airbags,' 'seatbelts'-it figures you'd get these ideas from those evangelists and their underhanded marketing tactics, constantly attacking us! Their cars lack maturity compared to our tried-and-tested fleet. And we've heard they're quite susceptible to Rust..."
Tbf seatbelts is more analogous not to language-level security features designed to prevent certain types of bugs altogether (as Rust intends to; it'd be "preventing cars from crashing"), but to system-level security features which prevent the bugs from being critical (i.e. car crash is less likely to be deadly). So their discussion actually was largely about seatbelts.
@@yurkoflisk That's fair and makes sense. By the way, the discussion on "seatbelts" in this sense is interesting, and the perspective of the functional safety experts is certainly important to hear. I am just a bit frustrated with this discussion in this specific context. For sure, memory safety doesn't help against kneecapping an operator to get a password. But how is this helpful here? If you can improve things at a language level, of course you will have fewer defects in programs, which is desirable regardless of system-level measures in place. Also, the "it's not just memory safety" argument cuts both ways, since languages like Rust are also about things like good defaults, a modern module system - that you can use today - preventing a class of C++ issues with ADL / ODR violations , proper destructive move semantics (as default, compared to copy), etc. The second argument that frustrates me is: "Just follow guidelines and use the proper set of tooling, and things are fine". Also this is true, technically. But the best support for preferring a strict compiler to guidelines, optional static analysis, linters and libraries is the very complaint from the discussion about people still not embracing RAII and generally writing a lot of "C/C++". If it can be done, it will be done. For the record, I have grown to love C++ even though I started to use it professionally around the same time I also started to learn Rust. I also have nothing but respect for the panelists. I am certainly glad to hear about developments such as the hardened compiler mode and safety profiles. At least for safety profiles, though, it is a bit disheartening to consider that C++29 is something of a best-case scenario for them to arrive.
To be fair, memory safety is the thing that has been a multi billion dollar security problem. Generalizing the conversation to "what does safety even mean" keeps us from making progress.
This. Was very functional safety focused and talking more about correctness in general while ignoring the fact that memory-safety issue contribute to 70% of the security issues and that this issue is C and C++ specific. The functional safety people normally do a hazard and risk analysis once, follow their ISO standard, use certified toolchains etc. They don't defend against a malicious attacker.
10:31 Don’t talk about Voldemore. Let’s instead state that we don’t need Rust because security bugs can still occur. What a way to avoid the subject 😂.
language as part of system we want c++ simple and safe language but "backward compatibility" and discussion goes on for ever, so c++is not simple and safe language.
Extending discussions into the happy hour should be mandatory in all C++ conferences.
talk about safety and security and then put all those guidelines like autosar and misra behind paywalls
Glad Bjarne, still here to speak for himself and to defend cpp.
Great talk to keep having.
This feels like a lot of repetitive whataboutism and gas lighting of what people want to address, making C++ more safe in the areas of memory safety. So things like dangling ref/ptr's and out of bounds. There seems to be resistance to talking about how they see these issues being mitigated. It took a fight to get the dangling issue in for loops addressed and seems like perfect is killing good here.
Just looking at CppCon 24, and there is no security track...
Is there any follow up of that discussion ?
Bjarne casually flexing.
Tbh, It would be enough to just say his name.
Feds: "Buffins discovered that seatbelts and airbags significantly lower the number of casualties in car accidents. Let's ensure they're included in future models."
Cpp: "There's no such thing as completely safe driving on public roads. What we need is training and incentives for responsible driving. Safety features alone won't save every driver, nor prevent all accidents."
Feds: "But surely, installing basic safety equipment can't hurt, no?"
Cpp: ""Well... we do offer optional seatbelts. On newer models, you can even add bumpers yourself, should you see the need. If you drive an ambulance, for instance, or something similar. But we believe in a tailored approach. Let individuals choose the safety features they find suitable for themselves. Some find seatbelts restrictive and might opt for, say, a louder horn to enhance safety. We could compile a guideline to suggest some of these measures as best practices. Maybe distribute them in public libraries.
Feds: "But the numbers look quite good for seatbelts and airbags, specifically. Plus, in our experience we are ignored if we just recommend something instead of making it mandatory by law.
Cpp: "...m..mandatory? No, that's not ideal. Mandating airbags would mean people have to fit new steering wheels, which won't accommodate older models. But people expect that they can install the latest steering wheels, always. Also, retrofitting all the older vehicles is not feasible, given their numbers. Plus, the added weight could slightly reduce speed."
Feds: "... you might have a point. We've heard complaints about fuel consumption and minor slowdowns in brands that introduced windshields previously, though overall they've become quite popular..."
Cpp: "Those aren't suited for low-level driving, you know."
Feds: ""Right. But we've come across a new brand that keeps up in acceleration and speed, and includes airbags and seatbelts. It also boasts easier installation of optional parts. Much simpler than your CBrake system, apparently."
Cpp: "Ah, of course! 'Airbags,' 'seatbelts'-it figures you'd get these ideas from those evangelists and their underhanded marketing tactics, constantly attacking us! Their cars lack maturity compared to our tried-and-tested fleet. And we've heard they're quite susceptible to Rust..."
Tbf seatbelts is more analogous not to language-level security features designed to prevent certain types of bugs altogether (as Rust intends to; it'd be "preventing cars from crashing"), but to system-level security features which prevent the bugs from being critical (i.e. car crash is less likely to be deadly). So their discussion actually was largely about seatbelts.
@@yurkoflisk That's fair and makes sense. By the way, the discussion on "seatbelts" in this sense is interesting, and the perspective of the functional safety experts is certainly important to hear.
I am just a bit frustrated with this discussion in this specific context. For sure, memory safety doesn't help against kneecapping an operator to get a password. But how is this helpful here? If you can improve things at a language level, of course you will have fewer defects in programs, which is desirable regardless of system-level measures in place. Also, the "it's not just memory safety" argument cuts both ways, since languages like Rust are also about things like good defaults, a modern module system - that you can use today - preventing a class of C++ issues with ADL / ODR violations , proper destructive move semantics (as default, compared to copy), etc.
The second argument that frustrates me is: "Just follow guidelines and use the proper set of tooling, and things are fine". Also this is true, technically. But the best support for preferring a strict compiler to guidelines, optional static analysis, linters and libraries is the very complaint from the discussion about people still not embracing RAII and generally writing a lot of "C/C++". If it can be done, it will be done.
For the record, I have grown to love C++ even though I started to use it professionally around the same time I also started to learn Rust. I also have nothing but respect for the panelists.
I am certainly glad to hear about developments such as the hardened compiler mode and safety profiles. At least for safety profiles, though, it is a bit disheartening to consider that C++29 is something of a best-case scenario for them to arrive.
lol true
To be fair, memory safety is the thing that has been a multi billion dollar security problem. Generalizing the conversation to "what does safety even mean" keeps us from making progress.
This. Was very functional safety focused and talking more about correctness in general while ignoring the fact that memory-safety issue contribute to 70% of the security issues and that this issue is C and C++ specific. The functional safety people normally do a hazard and risk analysis once, follow their ISO standard, use certified toolchains etc. They don't defend against a malicious attacker.
3:38 Lex Luthor?
10:31 Don’t talk about Voldemore.
Let’s instead state that we don’t need Rust because security bugs can still occur. What a way to avoid the subject 😂.
why no rust or other safer language members ?
language as part of system we want c++ simple and safe language but "backward compatibility" and discussion goes on for ever, so c++is not simple and safe language.
The problem is also: is there a safe and performant subset (or derivative) of c++ that isn't basically Rust in it's core.
@@markomacek920 If that is supposed to be a question: I would say yes.
"Why security is in focus now?" Did nobody notice there is a major war going on in Europe for two years now?