CppCast - Safety Critical C++

Episode Date: March 17, 2023

Andreas Weis joins Timur and Phil. After some news about Boost, std::format and performance, Andreas talks to us about safety critical application domains, safety in C++ in general, and the difference between safety in security. News Boost libraries may drop support for older language versions "Fun with printing tables with std::format and C++20" - Bartlomiej Filipek "C++20 Formatting Library, Parts 1. 2 and 3" - Gajendra Gulgulia "Decreasing the Number of Memory Accesses, 1/2" - Ivica Bogosavljevic using std::cpp (conference in Madrid) Links MUC++ (The Munich C++ User Group) ComicSansMs - Andreas on StackOverflow The EU's Cyber Resilience Act "Why not simply implement borrow checking in C++?" - Sean Baxter on Twitter P2771R0 - "Towards memory safety in C++" "Rust Safety is not superior to C++" - Bjarne Stroustrup P2739R0 - "A call to action: Think seriously about 'safety'; then do something sensible about it" P2759R1 - "DG Opinion on safety for ISO C++" P2723R1 - "Zero-initialize objects of automatic storage duration" D2795R0 - "Correct and incorrect code, and 'erroneous behaviour'" P2809R0 - "Trivial infinite loops are not Undefined Behavior" MISRA

Episode 356 of CppCast with guest Andreas Weiss, recorded 14th of March 2023. This episode is sponsored by JetBrains, smart ID blog posts and other C++-related news. Then, we are joined by Andreas Weiss. Andreas talks to us about his work and about safety and security in C++. Welcome to episode 356 of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Timo Dummler, joined by my co-host, Phil Nash. Phil, how are you doing today? I'm all right, Timo. How are you doing? I'm great. I finally completed the final step of the finish uh kind of documentation uh stuff so so it took me three months but i now

got a finnish id card which was very difficult to get because in order to get a finnish id card you need to have a finnish mobile number for which you need a bank account for which you need an id card so it's all kind of recursive yeah um but yeah i managed to sort that out so i think i'm now fully documented as a resident of finland and i have a bank account and an ID card and everything. And everything's great. So is it fair to say you are now finished? Well, yeah, I guess so. I mean, with that at least.

But yeah, there's a lot more to come. In particular, I started to look into organizing a local C++ meetup here because apparently Finland doesn't have one. So kind of in the first baby steps to make that happen. So hopefully I will have to announce more about that at some later point in time. Yeah, we should announce it on the show. Is this the show? I don't know.

Yeah, let's do that next time's do that next time, perhaps. Right. Yep. All right. So at the top of every episode, I'd like to read a piece of feedback. This one is an email that we received. It says, hey, thanks for the show. I used to watch it occasionally on YouTube.

Since there were no posts on the channel, I assumed there were no more episodes until I found out. YouTube is my favorite way to consume content, and I would like to encourage you to reconsider posting on YouTube. Phil, what do you say about that? It's an interesting request because we've not really had many mentions in the feedback about YouTube. I think maybe two in total, including this one. So I don't think we're going to return to doing full video like Rob and Jason were doing towards the end. it's a lot of extra work and some other consequences that we're trying to avoid for now obviously there's a real demand we'll consider it but for this request really just knowing about the show and being able to hear the audio there was the main thing so one thing we could do is just put the audio up to maybe with the the show

artwork as a placeholder um and if that helps a few people, then that should be pretty low overhead. So we'll consider doing that. All right. So then maybe you should just let us know if you're listening to this, if that's useful to you. And then if it is,

then you're going to make it happen, right, Phil? Yep, absolutely. I might even do that for this episode. So if you're listening to this on YouTube, you know it worked. We do also have a new website which just went live a few days ago as you as you listen to this it's completely new website obviously the content is the same the visual design is not quite finalized that that may still change but i really wanted to get it onto this new infrastructure so that i had 100 control of the code base and no more way around so we can make a few changes

here and there and that the first big changes you'll notice are that all of the episodes were all on one page all of the guests were on one page so you can easily search them that was one thing that um i did find a bit frustrating before is trying to find a specific episode was actually quite hard. So that should be a lot easier. I usually did binary search when I was trying to find out if a particular person had been on the show. I was like, okay, it's like letter S, so it's probably somewhere there.

Oh, no, too far. Let's skip back. Yeah, I consider it more sort of a guided binary search. It's quite binary. It's a bit more weighted than that, but I know exactly what you mean. Anyway, that should be a thing of the past. So let us know what you think about that. So there will be a few more changes to come. The other change as a consequence of this to be aware of is that it gets a little bit complicated. There's a new RSS feed, which is what the podcast clients will be using.

Now, originally, the website was run on Libsyn, which is, well, was and still is, where the audio files are hosted. When Rob introduced the old new site, that also produced an RSS feed, and the links on the page were to that one but the Libsyn one was still running and I believe that people that subscribed at that time and maybe even after then got the Libsyn feed and still have it now and still relying on it whereas other people may have picked up the the feed from the old site so the Libsyn one hasn't changed at least not yet but if if you do see any problems with your RSS feed or if for some reason you're not hearing this episode,

in which case you may not hear this message, but do let us know. But I've run it through many validators and it all seems to be very valid. But it is a change to quite a critical part of the infrastructure. So I'd appreciate any feedback. At some point, we do want to try and consolidate down to one feed

so we don't have these feeds in two places. We're going to have to work out how to deal with that. So what's the best way currently for people to subscribe to the feed? So one thing I had meant to check and I haven't done yet, but I believe that on the Apple podcast site, so formerly iTunes, that's the directory, the master directory on the the apple podcast site so formerly itunes that's the directory that's like the master directory on the internet for all podcasts um i believe that still refers to the libsyn feed i'm not 100 sure because i don't have access to it yet um i still need to follow up with

jay there we've uh we've rubbed together so we'll change it there and then hopefully most clients will pick it up from there but there may be some some clients that just cash the Lipson one for longer. We don't want to lose those people. So I'm giving you some warning now so you can watch for this. And if we suddenly disappear from your feeds, then maybe it's time to resubscribe. But we'll cross that bridge when it comes to it. All right. We'd like to hear your thoughts about the show.

You can always reach out to us on Twitter or Mastodon or email us at feedback at cppcast.com. Joining us today is Andreas Weiss. Andreas has been writing C++ code in many different domains, from real-time graphics to distributed applications to embedded systems. As a library writer by nature, he enjoys writing portable code and exposing complex functionalities through simple RGT-type interfaces, both of which C++ allows him to do extensively. Andreas is one of the co-organizers of the Munich C++ user group, which allows him to share this passion with others on a regular basis. He currently works for Woven Planet, where he focuses on building modern software for use in safety-critical systems.

Andreas, welcome to the show. Hi there. Thanks for having me. Now, we are going to cover, I think, most to the show. Hi there. Thanks for having me. Now, we are going to cover, I think, most of the points in your bio later through the show, but one thing I do want to pick on is the Munich C++ user group that you're co-host of. Yes. The reason I want to pick on that is because I think for the last few years now, the very

last meetup of the year always seems to have featured myself and Timo. Exactly. That's our little Christmas tradition in Munich. We'll see how long we can keep that running for. But yeah, it's a great meetup. Yeah, so far it's always been great. The Christmas meetup is always one of the highlights for us. It's always a great pleasure to be in Munich. I love that meetup. It's always a great pleasure to be in Munich. I love that meetup.

It's a nice community there. Yeah. And we just started actually like the Christmas meetup last year was the first in-person meetup that we did since the pandemic. And now in this year, we started doing regular in-person meetups again. So that's also great to see the people in person again. Right. person meetups again so that's that's also great to see the people in person again right so andreas we'll get more into your bio and your work just in a few minutes but we have a couple of news articles to talk about so feel free to comment on any of these okay all right the first one is a

message from the boost release team and it says that boost library authors and maintainers are free to drop support for old c++ standards in their libraries at any time. I guess that's from now on. This includes libraries that other Boost libraries depend on. It even includes core libraries like Boost.core or Boost Static Assert. We ask that maintainers do the right thing by all our users, which may include other Boost libraries, by announcing a future breakage at least two Boost releases in advance. When that eventual release time arrives, if Boost Libraries are broken in older standards mode,

due to another Boost Library dropping support, it will not block the Boost Release. So basically they're saying, if you're maintaining a Boost Library, you want to move to C++ 14 or 17 or 20 or whatever, you're free to do so as long as you don't, as long as you give your users a little bit of an advance warning.

So that's kind of how I interpret this. So I think this is going to be a bit of a significant change because I remember a few years ago, there were still quite a few boost libraries that were supporting kind of C++98. So it sounds like they're kind of changing gears a little bit. So I'm curious what impact that's going to have on the community and whether it's going to make more people move

to the newer standards perhaps. Yeah, my reading of this was actually that it's not specifically a change. It's just a clarification of what's always been the case, or at least been the case for a long time. And if anybody listening to this knows for sure, including the people that wrote this post, then do let us know. But that's my reading, that this has always been the case, but it's not necessarily been widely understood. So it's a clarification and emphasising the fact there'll be two boost releases before the change, before the dropping of support for something comes into fact.

But also that gives the authors of any dependent libraries a chance to fork their dependencies and incorporate them into their own code base. So if they want to maintain support for an older C++ version, they can still do that. So this is in the spirit of Boost, not Boost Spirit, but the spirit of Boost, that it was always about being on the bleeding edge of C++.

But I think for a lot of people in recent years, particularly since c++ 11 boost has sometimes been seen as almost like a polyfill library providing some of those c++ 11 features without c++ 11 and hopefully that's not as necessary these days as it used to be but maybe there's still a bit of that out there yeah i remember kind of there were a bunch of there are a bunch of regular kind of community service there's one from jetbrains there's one from meeting c++ i think there's one from the c++ foundation so there's like at least those three and one question is always

which standard are you using and i think uh most people are now on c++ 17 or at least C++ 14. So, yeah. Yeah, I think the last point that you mentioned, Phil, like giving an early warning to other Boost libraries is a pretty significant part here because a lot of the Boost libraries are very tightly coupled with other parts of Boost in terms of dependencies. So even if I, as a maintainer of one library, decide that I would like to support my C++98 clients, if one of the core libraries decides to drop support for that, that's inevitably

going to impact me. And I think that's a big problem here because like boost i think they have improved there uh to just somewhat in in the last years but uh they still don't have the best management of their dependencies it's still like one one big ball of things the other thing was that there were a number of blog posts that caught my attention this week and last week. First one is by Bartwomje Filipek called Fun with Printing Tables with stdformat and C++20. And he's basically taking a stdmap,

which has some values in it, and prints it as a pretty formatted table. And he does that first in C++17, and then he does that in C++20 using stdformat, which obviously looks a lot nicer. And so I thought that was a really nice practical application of std format.

It will, of course, be even better in CSS 23 because then we don't have to do std cout, shift, shift, std format anymore. We can just use std print. But other than that, I think that was a pretty nice example of how to use it in kind of relatively straightforward code that just gets a lot nicer so i thought that was nice and

speaking of set format there was actually another blog post also about set format actually not even a blog post but the new series of three blog posts by apology if i don't pronounce this name correctly gajajendra Guldulia, also about Stratformat. And it's kind of a tutorial that starts from zero and explains how Stratformat works. Like the placeholders using the curly braces, the available format specifiers, et cetera. It's like a three-part kind of tutorial.

And this is really nice because I haven't really seen this before. I don't think there really was a good beginner tutorial on SID format before. At least I haven't seen one. I remember when I was preparing my CppCon keynote last year and I had a section about SID format in there. I was looking for something like this and I couldn't find anything. Like a beginner-friendly kind of introduction.

So I'm very happy that this exists now. So there's like two blog posts about the format that I found quite interesting. Yeah, I'm a big fan of format. Like since it was included in C++20, I actually got into the habit of including the FMT library that is based on in all of my personal projects. And I never look back.

I really like it. It's quite nice. And I think it's really good that we start seeing more of these introductory blog posts to spread the good news that it's out there and that it does awesome stuff. I think this is a good timing as well because std format is now starting to be supported in most, if not all, of the major compilers. Although I noticed that these

two articles did seem to differ on that point. One of them, I think the second one, dated in March, said that it wasn't yet supported in GCC or Clang. Whereas the other one said that as of February, it was. So I'm not quite sure which it is.

Maybe std format is here. It's just not evenly distributed. One thing that I would like to see more resources on in the future, so both of these posts focus on how you would use format to print some data that you have lying around and the various options for aligning the data and formatting numbers and stuff like that. But what also changed completely if you were coming from an IO streams world is how you enable formatting for your own custom data types.

And that's, I think, a bit more involved than it used to be in IO streams. And there's not too many resources out there right now that explain how that works. and that's, I think, a bit more involved than it used to be in iOS streams. And there's not too many resources out there right now that explain how that part of the mechanism works. And I hope we will see some more resources on that in the future as well. I just looked up, by the way, the compiler support for std format according to CPP reference

and all of GCC, Clang and MSVC are now supported in the latest version apple clang however does not so if you're targeting mac os or ios or like those apple platforms then you have to wait a little bit longer yeah i got the impression it's fairly fairly recently that that's become the case so as i say good timing for these articles okay yeah there's one more blog post that caught my attention by ivica bogoslavovich decreasing the number of memory accesses and part one of two so i suppose that part two is going to be coming out soon and that was all about improving performance and he's kind of looking at memory

bound loops and optimizing their performance by actually decreasing the total number of memory accesses so like loads and stores. And sometimes actually the work that's being done is increased, but like the memory access, the number of memory accesses decreased and that decreases the overall performance, sorry, improves the overall performance of the code. So you mentioned various techniques such as loop fusion.

And you also had some nice examples of how to use ranges effectively, which is another C++ penny feature that becomes more and more popular. So I thought that was very interesting, kind of a more performance-focused blog post. Yeah, I think you did make the point that using ranges effectively gives you loop Fusion, even though you're not writing it manually. In fact, most of the posts did seem to be about loop Fusion, which to me sounded like a new sort of dance style,

but maybe that's just me. And Iwisa will also be speaking at the user group in Munich tomorrow, March 15th. That's very cool. What is he going to be talking about? Also about performance. That seems to be his go-to topic, and in particular about memory and performance.

Yeah, that sounds really interesting. Can people attend this online, or is it in person only now? No, it is actually hybrid. So if you go to our Meetup page, there is a link how you can join a live stream. And hopefully we will also have a recording afterwards to put online so we should probably put that link to into our show notes phil right absolutely yeah all right and then last piece of news which is conference news another little snippet of conference news using std cpp which is a conference taking place in madrid in Spain, has just announced their program.

The registration is open. It's a two-day conference taking place at Carlos III University in Madrid, 27th and 28th of April. So it's actually just something like six weeks away. Invited speakers are Dietmar Kühl, Odin Holmes, Mateusz Pusch, and myself. And the conferences are free to attend also, just like the Italian one,

with a little difference is that starting this year, they require a donation to the university alumni scholarship program, but it's fairly low. I think the minimum required amount of donation is something like 20 euros. So it's very affordable and it's all going to help the university and students. So I think that's a good cause. I was there in 2019 um i spoke there already once and it's um yeah it's a pretty good pretty good vibe there taking place in the universities and there's location it's in madrid which is a cool city to hang out in so i'm looking forward to uh be back

there next month and um yeah i think that's that's an interesting one so registration is open i think this is the first one back in person post-pandemic. Yes, correct. They had a bunch of them yearly before the pandemic, but this is the first one after the pandemic. And also the previous ones, including the one that I spoke at, they were kind of half English, half Spanish. Some of the talks are Spanish, some of the talks are English,

and it was one day. But starting this year, it's two days and it's english only so it's more international friendly so even if you don't speak any spanish uh you can attend interesting yes it's one that i've been wanting to go to for years and the timing never seems to have worked out so not been yet and i won't make it this year unfortunately so hopefully they'll still be running next year all right i think it's time now to switch to our main topic for today which is safety and security in c++ and so we invited andreas on the show today who knows a thing or two about that so maybe you can start by telling us a little bit about what you do and what you're interested in

oh yeah sure so um i work in the automotive industry at the moment and have been for a couple of years. I sort of stumbled into that when I was recruited by BMW because I live in Munich and BMW is one of the major employers here. So before that, I actually did not work in automotive at all, even though I studied computer science in Munich. And if you're so inclined, actually,

when you're studying computer science in Munich, you can choose your curriculum in a way that it is very automotive focused. So they offer courses for all the things that you encounter there. But I did not take any of those courses. So I was completely clueless when I joined BMW and then sort of learned in the field what it means to write safety-critical software. And yeah, an important distinction here is also that there is a difference between safety and security and i'm not a security expert by a long shot i've been focusing almost exclusively on on safety although if you look at like what it means for for an engineer working in the field in the end like the implications that

it has for the everyday work those implications implications are often very similar for both concerns. So you said you concern yourself with safety but not with security. What's the difference between the two? So what safety is worrying about is the functionality of the product so there's there's two aspects to this the one is the the safety of the intended functionality so that is like the the thing is doing what it's supposed to do but it should be safe to use right so is that like the car doesn't explode while you're trying to exactly like the the car doesn't explode while you're trying to do something? Exactly, like the car doesn't explode, right? Like the steering wheel does what you would expect it to do.

But also stuff like boundary conditions. Like, for example, if you have certain sensors that might stop working under certain weather conditions, right? Then that is to be expected, right? Because like bad weather is just something that happens you have a lot of that right now here in finland oh yeah exactly yeah and uh yeah so the functionality should be able to um like still do reasonable things in in bad weather in in contrast to that we also have functional safety and that that is actually, especially in the software world, that is the much bigger concern. And there we worry about what happens if something goes wrong.

So if the functionality is not operating within the normal parameters, for example, because of a hardware defect or because of a software bug. And basically what you're worrying about there is like bugs happen, right? And hardware defects happen. So we cannot really rule that out. But if a bug happens or if a defect happens, we don't want any human to come to harm as a result of that. And that is what functional safety is trying to achieve. So if the functionality does not behave as expected, then at least there should be no harm to a human being resulting from that. And then if we contrast that with security, that is not just malfunction of a functionality,

but that is like we're being deliberately attacked, right? So like somebody is trying to get access to the car, even though they're not supposed to have, and we want to avoid that from happening. This also includes stuff like data protection, right? So if we send send your personal data, like all of the modern cars these days, like most electronic devices,

collect some kind of personal data, right? If this personal data is leaked in some form and somebody who is not supposed to access it can access it, there's not necessarily a safety concern, right? Because maybe it's not harmful that they have access to this data. But it might be a big security concern because it's still undesirable

and it might still have consequences that like even legal consequences. Okay, so we talked about safety and security kind of already a little bit, but obviously the reason we're here today is that it's been one of the hot topics in the C++ community. And actually last year, several US organizations started now published a new Cyber Resilience Act where they're also planning to regulate software in the sense that you're not supposed to use unsafe languages

for certain things. Although it seems like they haven't quite figured out yet exactly what the standard is going to be that they're going to ask software companies to adhere to. This seems to be a work in progress. But yeah, there seems to be a big push from both government agencies and regulation staff might be coming to move away from languages like C++ that have safety and security concerns.

So what's your view on that? Does C++ have a safety and security problem? Do we need to do something about that now? And what has changed from a few years ago when people weren't really talking about this quite as much? Yeah, I think it's pretty obvious if you look at the list of vulnerabilities that are found in software

that there's a lot of stuff popping up there that shouldn't be there, right? So we could certainly do more with regards to safety than what we are doing. I think what is important about these efforts that are now coming up is that I don't perceive them, so this is now my personal interpretation, but I don't perceive them as targeting C or C++ in particular, but more like how we do software development as a whole, right? So what these proposals are calling for is regulation. And so far, most of the software world is not regulated.

If I want to write an instant messaging application, for example, for a phone, I can just do that. I can just sit down in my garage, write this application, deploy it on the App Store. No government-certified agency will ever look over that or audit that. And then only once I have a billion users and my application starts getting hacked and we see real problems in the field, that is when people might question that. Like, oh, is this actually audited and how was it developed? And that is causing real problems right like we we see we see now that like technology is becoming such a big part of our lives that maybe that approach is not the best anymore that maybe we need like regulations that say no no you can't just like throw the software out there

you actually need to follow certain guidelines before but that is is a big change to how we used to work in the software world. And that has wide-ranging implications. And it certainly won't make software development more fun. Right now, it's sort of this careless world where you can just try stuff out and not really have to worry too much about the implications. But that might change now because of these things. And I think that's a problem that goes far beyond just CNC++. That's like a general thing that we have to get used to that we will be held more accountable in the future for what our software does.

So thinking specifically about the automotive industry, as you are in that space, how do you address particularly safety but also security in that industry? The automotive industry is one of those industries that are already regulated.

There's other industries like aerospace, nuclear power plants, medical devices, right? Like all of these where it's pretty obvious that if the software misbehaves, you have a big problem. You already have regulations in place. And there is international standards that describe how you should do software development in those fields so that bad things don't happen, so that your software is not harming people. So if we're talking about safety here, and in particular functional safety, which is the biggest concern here, then the general standard here is ISO 61508.

That's an ISO standard from the late 90s, early 2000s, which lays out these overall guidelines, how you should do software development in such fields. And then there exists a bunch of specializations of this standard where they adapt it to particular domains. So like for automotive, for example, there exists ISO 26262, which is functional safety for road vehicles. That standard is a little bit younger. It's like from the 2010s.

But it's basically the same ideas, just a little bit more specific to the domain of automotive. And basically, if you look at those standards, what they say is something that, like in the software world, has a bit of a bad reputation. It's that you do v-model development. That's basically what they require you to do. Never heard that term. So you probably heard the waterfall. Yes.

Yeah. That's what everybody tells you not to do, right? Exactly. That's what everybody tells you not to do. And the vModel is basically the waterfall and then something stacked on top of that. So in the V model, they say you have to start by actually gathering all of your requirements, right? So you have to completely figure out what your system is supposed to do,

what could go wrong, and how the functionality is actually going to behave. And you have to nail all of that down. And after you do that, you move on to a system design phase where you design the system architecture on a higher level. And then you break that down into smaller components until eventually you arrive at the unit level. So that's basically exactly the same as you would have in the waterfall. So you go through all of these stages where you start at the big system view

and then you go into more and more detail, but you only go into the detail once you have the previous stage finished. And now what the vModel also does is once you are at the bottom and you implement your unit, you now have to validate that what you implement does the right thing. So the second half of the V is like you go up the same way that you went down before in the waterfall. Swimming upstream. Exactly. So you have to write unit tests to verify that your units are doing the right thing. Then you have to write integration tests, and then you have to write integration tests

and then you have to write system tests and at each level you basically validate the design that that happened on that same level as you were going down it's interesting that it's so different from you know what you know some people practice as kind of agile development and things like that for example in one of ph's workshops about TDD, I learned that you should always write the tests first. And now you're saying that this is actually not what the vModels tells you to do. Exactly, yeah.

And that brings us already to the core of the problem, right? We have, for good reasons, been trying to get away from this waterfall style of development in software. And in particular, one of the main advantages of software is that making changes is comparatively easy. If you compare it to stuff like hardware design or mechanical engineering, making changes in software is rather cheap and easy. And now this model basically forces you into a mode of working where making changes becomes prohibitively expensive again. And that's not nice, right? Because you lose a lot of flexibility there and you lose a lot of good stuff.

But at the same time, if you're thinking about, yeah, you really don't want bad stuff to happen because of those changes, you can see how you could have a legitimate interest here in making changes be at least somewhat harder than it is in Agile, right? It's like there's some assumptions that you just can't change, right? If you want to make a change that fundamentally impacts a safety assumption that you did,

then at least stop and think about it, right? Don't just make the change. And so we have this field of tension here where these are both legitimate concerns, and we now have to land somewhere between these both extremes where it's reasonable. And traditionally, in the regulated industries, we were leaning far more towards the conservative side, so doing the traditional v model approach but of course like even those industries see that being more agile has its advantages so they have been playing around with like how could we maybe soften uh the process a little bit to become more agile but it's difficult right because you don't you don't want to give up too much on the safety guarantees. So you can't change everything all at once.

So what you're saying is that move fast and break things is not a great slogan for the automotive industry? Exactly, yeah. Like we like to move fast, but we don't like to break things. I should hope not. That's interesting. So we are a C++ podcast. So if I may just zoom in a little bit more,

like you talked about kind of the general model of how you develop software, but now you're using C++ and C++, as you all know, has unbounded undefined behavior where you kind of can't really in principle prove that a program behaves correctly or doesn't have undefined behavior.

That's like solving the halting problem, right? With the specification that we have in the C++ standard. So how do you square the circle here? Yeah, like in an ideal world, and this is actually what the standards also say. Like if you look at the functional safety standard, how they want you to write software, they say use a programming language that has fully defined behavior.

In the ideal case, even a formal specification that just says, this is what it does, and there's no ambiguity. And they also say a bunch of other things like, for example, you should have a structured programming language. That's a thing that they are pretty insistent on. But then if you read a little bit further, the realities of everyday development creep in

because then you might have some projects where you need to use assembly language. And assembly language is not structured programming. So what do you do? You have a project where you just can't use a higher level language because of constraints. Maybe you don't even have a compiler for the hardware, or maybe the compiler is just not suited for what you want to do. So what do you do now? You just don't ship? No. They say you can use assembly, but then everything becomes much more difficult. So you now have to address basically all of these concerns that you wouldn't have had in structured languages that you now also need to address because you're using assembly language. And that might have wide-ranging implications for the development process. So you basically need to realign your entire development process to account for the fact

that you're using this language with these undesirable properties. And we have been doing that for C++ and C as well for decades now. And we do that basically, say, one big cornerstone that we have there is the use of coding guidelines. So this is also something that these safety standards in particular say, if your language is deficient in one of these aspects, then you need to have other means in place that compensate for this. And one of the most important tools there is coding guidelines. So that's why if you're working in a regulated industry, you almost always have to follow like some form of coding guideline for your for your projects that's interesting so is that stuff like misra i know that c-line

supports it out of the box but i've never actually used it myself exactly yeah so like misra um to before misra did coding guidelines they were actually a standards committee, and they wrote one of these functional safety standards that was a precursor to 61508. But these days, what MISRA is mostly known for is the coding guidelines, which they have. So they have coding guidelines for C and then coding guidelines for C++. These are two completely different documents, but these are among the most well-established guidelines for writing safety-critical software. What they try to do is, in particular, what you asked in the beginning, what do we do if the language has undefined behavior? They try to force you to write code in a way that you have as little undefined behavior as possible. So, ideally, no undefined behavior as possible so ideally

no undefined behavior that is in practice very hard to achieve but they try to get you as close to undefined behavior as close to no undefined behavior as they can right so as i said like misra i haven't worked with personally but uh it's kind of i know that people use it what i hear about more is stuff like the core guidelines which diana among other people is advocating for quite a lot right is that also in that space or is that is that different so the the core guidelines like if you look through the core guidelines and you look through a document like the the mizura c++ guidelines you will find a lot of commonalities i think the main difference is that

what the core guidelines want you to do is they want you to write better code, right? They want you to write code that is easy to maintain, easy to reason about. And that is not necessarily something that MISRA wants. Like if MISRA has a rule where they see, okay, the code will be super ugly in the end

and a lot harder to maintain, but it will be safer. They might actually have a rule that then forces you to write the less pretty code if it makes the program safer. The core guidelines would never do that, right?

The core guidelines, they want you to write good code and they don't want to compromise too much for safety based on that. So I think that is, philosophically speaking, that is, I think, the biggest difference between the two. And if you're not working in a regulated industry for this reason, I think the core guidelines are probably the better document to follow. Because some of the miserable rules can be a better document to follow because some of the MISRA rules can be a real pain to follow and they really change how your code looks like and not always for the better. I would like to perhaps slightly reframe what you just said, which I agree with,

but about MISRA not being so interested in, you know, how well written the code is, how readable and maintainable it is. I think those things are valued by the MISRA committee and the guidelines. But the priority is that it must be safe first and maintainable second, whereas the core guidelines is almost like the reverse.

Exactly. Yeah. No, that's, yeah. I wasn't trying to say that MISRA is deliberately trying to make your code more ugly, but yeah,++ at the time. So if you've seen that, you've been a bit put off by it. The new upcoming MISRA standard, I think you'll hopefully agree, is a lot more modern and sort of tuned into modern idioms, while also still curtailing some of them when necessary.

Is that fair to say? Yeah, exactly. That one is based on C++14, right? 17. 17, actually. There has been a set of coding guidelines published by the Autosar Consortium, which is

a standard for automotive software. They published their own guidelines because there was no MISRA version targeting C++11 and 14. But that document has

now been, like Autosar is not maintaining that anymore, that has been handed over to MISRA. And MISRA is now working on a new revision of their C++ coding guidelines for C++ 17. And I have actually been part of that working group that is writing that standard for about five years now. So if it all goes wrong, you can write your letter as a complaint to Andreas.

Exactly, yes. I'm always happy to receive complaints. But it's surprisingly hard to write these coding guidelines. We have long discussions. We have lots of very smart people in the working group, but we have really long discussions about some of those rules. And even stuff that seems obvious at first glance, if you really try to think it through, you unearth some surprising difficulties there. Yeah, I work for a static analysis tools company.

So we do that as well. I've seen that firsthand and I completely agree. It's very non-intuitive sometimes, all the interplay between things. Talking of static analyzers and sanitizers, how do they help here? So the guidelines are only as good as the enforcement of the guidelines, right? So you can always write a guideline that just says you must not have any undefined behavior in your program. But if you cannot enforce that, then it is not going to do much good in practice. So you need to, when writing the guidelines already, you need to think about how the tooling is going to help you to enforce those guidelines in the end.

And when we're talking about functional safety in particular, then this usually means static analysis. So in MISRA, you won't find a rule that relies on dynamic analysis. That's just not in there, right? It has to be statically checkable. That is how those rules are enforced. It's not possible for all the rules. Sometimes there are rules where you cannot reliably diagnose it in the general case, but you can still diagnose enough interesting cases in practice that it's worth having the rule. But the preference is always to have something where you can really decide it statically in all the cases. Sanitizers are an interesting tool

because they're comparatively new. They haven't been around for that long. And they're a dynamic analysis tool. And sanitizers are not supposed to be switched on in production, right? So when you're making a safety argument, it's hard to rely on something from the sanitizer because if something only goes wrong in the field,

then the sanitizer is not there to help you. So they are, of course, important for testing and validation because they do help you catch bugs. And the safety standards actually say that you are required to use the state-of-the-art tools to ensure software correctness. And sanitizers, I think these days, are a very important building block in that. And it's not really responsible not to use them. But when it comes to really building a safety argument,

as a lot of those standards require you to do, and write the paperwork for that, then they are a lot less useful. They're a useful development tool, but for these safety practices, I think their role is not as important as you might think. So while we're talking about static analysis, it's a good time to do our sponsor break because this episode once again is sponsored by sonar the home of clean code now sonar have a few tools that can help us here sonar lint is a free plugin

for your ide and helps you to find and fix bugs and security issues from the moment you start writing code. But you can also add Sonar Cube or Sonar Cloud to extend your CICD pipeline and enable your whole team to deliver code consistently and efficiently on every check-in or pull request. The Sonar Cloud is completely free for open source projects and integrates with all of the main cloud DevOps platforms. All right. So we talked about kind of where we are now and what we do to kind of circumvent or work with the C++ language in those fields.

What I'm curious about is where should we go with C++ going forward? So Andreas, you said that ideally you want to be able to statically check for all undefined behavior but obviously with today's C++ it's not possible and so you said that you have guidelines where you try to kind of subset the language

in a way that certain constructs are maybe valid, but just not valid according to the guidelines. But I guess you still have these cases that even with those guidelines and even with those static analyzers, you just can't prove. So the idea is, why don't we use a standard programming language where kind of safety and particular memory safety is kind of built in by design because it's specified to be that way and obviously rust is an example with its borrow checker and all people are saying this is the solution and val follows a similar approach

we had an episode on that and last time we talked to richard smith about carbon we discussed safety as well and so while carbon doesn't have a guarantee like this, we actually tweeted about the episode. And then there was a bunch of replies and it kind of turned into a discussion about safety on that Twitter thread. And I remember Sean Baxter, who's the author of Circle, wrote, why not simply implement borrow checking and C++?

He literally wrote that in a tweet. And is that what we should be doing? Is that a viable approach? Is that going to solve the problem in a more effective way than what we're doing now? That would be very nice. Yeah.

If I could just implement borrow checking in C++ and be done, that would be nice. In practice, it's a lot harder. So there were actually people that tried to do this with different approaches. There's a paper out there by Google from, I think, the Chromium team that did this and actually claimed that it cannot be done for various reasons. But they also chose a very specific approach, how they were trying to achieve this.

So I would be careful here with saying it's impossible. There are some research projects that try to do this, but in practice, it's a lot harder than it sounds. It's not obvious. You cannot just take the rules that Rust has and apply them to C++ and everything will just work.

It's a too restrictive model. It has wide-ranging implications for what idioms are still allowed in the language, and you need to account for that. And Rust sort of grew around those restrictions and has found good solutions to all of them. But we don't have a lot of those solutions available in C++.

That being said, the general idea behind the Rust Borrow Checker that you use local reasoning, static analysis, to prove certain properties of your code locally, and then propagate that information through the type system in a way that it composes. I think that's an extremely powerful idea, and that's an idea that C++ can learn from. And I see that surface in different forms

in various places already today. We just don't have that worked out to a degree like Rust has it, where it gives you already all of these really powerful guarantees on a global level. Yeah, so there are quite a few approaches here. I read a paper by Thomas Ne neumann p2771 towards memory

safety and c++ where he basically um proposes to add annotations to mark lifetime and to mark aliasing and to mark like dependencies between objects when you pass them around which is kind of a bit different from borrow checking per se, but tries to solve the same problem, I guess. Have you heard about this one? Yeah, Thomas was actually presenting that also to the WG21 working group, so to the ISO C++ committee working group for safety and security. Oh, I must have missed that. Yeah, it was just last week.

I was in Issaquah. Oh, okay. That was a telecom. Exactly, it was it was just last week yeah oh okay that was a telecom exactly it was the telecom last week so and like his his paper is still in a very early stage right it's it's just a simple prototype that is exploring in in this general direction but he already i think the paper does a good job at pointing out some of the difficulties that you encounter even early on when you try to apply such an approach. But it also, I think, shows quite some promise with regards to what you actually can show with relatively little effort. So I think it's a good starting point. It obviously needs a lot more work before it's something that you can ship in a compiler and something that provides value

for a real-world project at scale. But I think it is exactly the kind of things that people should be looking at to improve the situation in the C++ world. Yeah, I guess there are several other approaches. People are really working on this now. So I remember that Bjarne had a paper recently. Actually, he had an article where he was claiming that

Rust safety is not superior to C++, which I found interesting. I think that was quite controversial. And then he wrote an opinion paper that was p27 39 a call to action think seriously about safety then do something sensible with it which i think also had quite a mixed response so there's people who are claiming this is the solution there's people who are claiming now this is rather detached from like actual research on safety and security but basically he's proposing this like three-pronged approach of kind of enforced local static analysis which is kind of a bit similar to um the other approach

you just discussed and then cody guidelines which is what we talked about and then kind of new library tools that can serve as kind of like clever annotations that kind of hook into the type system this is kind of how i understand it. I guess, again, somewhat similar, but also different approach to solve the same problem. Yeah, I think what Bjarne is trying to do and is described in those papers is actually quite similar to the approach in Thomas' paper. So Bjarne's work is based on the core guidelines. And if you remember

back when the core guidelines were introduced, like five, six years ago now at CppCon, this was one of the main selling points for the core guidelines that they said, if you follow these rules, then you won't have any memory leaks, for example, anymore, or you won't have any buffer overflows anymore. Because we can, through local analysis, catch all of the cases where you would break the model and prevent you from doing this. And then we always keep you in this safe world where all the potentially unsafe operations are runtime checked, and you can never accidentally do something bad. And the way that this was achieved was through the interplay of these three mechanisms that you had.

The guidelines, on the one hand that are laying out like what are you allowed to do what what are you not allowed to do then the support library which is important because it gives you the types that perform the runtime checks but it also gives you those types that serve as annotations for the properties like the GSL non-null pointer, for example, that just communicates, hey, this pointer cannot be null, or the other was the GSL owner. That's actually a better example.

So the GSL owner, it's just a normal pointer, but it communicates this additional semantics that the pointer has ownership and needs to be released before going out of scope. So this does not generate any additional code at runtime, but it communicates to the analysis tool a property about the data. And then the third thing that you need is the actual analysis tool that brings the two together, that on the one hand understands the rules from the guidelines and is able to enforce them, and on the other hand understands

these special semantic properties from those helper types and takes them into account for the analysis. And all of those three together, you get something that is, I would say, pretty close in the philosophy to what the Rust Borough Checker is doing. But of course, it's not as tightly integrated with the language because it's something that we now invent on top and not something that has grown with the language for all this time. Yeah, so one more approach that I want to mention is that I've seen. This is super fascinating.

I've seen actually your colleague, JF Bastian from Woven Planet, who suggests not to look at this whole problem from a first principles standpoint principles kind of standpoint, like some of the other approaches, but do this thing that in Germany, in German, there is like a beautiful word for the salami tactic. How do you translate that to English?

Like salami slicing tactics, where you like approach, like you solve a problem by like slicing off like one slice at a time, right? And so he has this uh he had this so he says we should just eliminate undefined behavior like one by one like so he had this paper that we discussed in issaquah about basically initializing uh variables to zero by default so you don't get uninitialized variables anymore and the ub associated with that he has a

new paper that is i believe is going to be in the mailing that's coming out this week about making trivial infinite loops are non-ub currently there there are ub if you have an infinite loop in your code um that's ub so it's kind of not this like how do we change c++ fundamentally or how do we change C++ fundamentally, or how do we introduce new design elements to make it safe, but rather than attacking one source of UB at the time and just kind of eliminate the things that are known to lead to a particular amount of vulnerabilities and kind of remove them one by one.

So I guess that's another valid approach, which is kind of different. I guess it's coming more from a security perspective rather than a kind of safety yeah and it's it's a it's a very practical approach right because like jf argues really well why making this change now gives you immediate benefits like it how it like resolves problems that we have in the world, how it stops vulnerabilities that we are dealing with every day. And what I think is also important

is that he makes a strong case that there's not a lot of reasons not to make these changes, right? Because the reason why we have this UB and the optimizations that this UB allows are actually, their impact is not that big compared to what you would gain by getting rid of the UB and aiming for the safer behavior. change in direction for C++, because for a long time, the way that the language evolved was that we were very reluctant to remove undefined behavior from the language, but we were very eager in compilers to exploit existing undefined behaviors for aggressive optimization.

And we're now, if we adopt this direction for JF, it's more that, yeah, these aggressive optimizations are not really, we're not really benefiting that much from them. Especially like if you look at the average program, of course, there's always some programs that heavily benefit from them. But for them, maybe you have an opt-in mechanism to the old behavior, right? But the default should be the safe behavior. And for most programs, that's okay from the perspective of optimization and performance. But the benefit that you get on the other hand,

the increase in safety is tremendous, right? And that's why this is worth doing. And I think it makes a really strong case here of course this is not magically going to make all the programs safe and secure right these are like solving like really small issues but it's small issues that cause a lot of pain in practice so the the impact that those changes potentially have is just really big. So it's worth doing it. I don't think that this alone will be enough to address some of those challenges that are

now being posed towards C++. But I also think it would be foolish not to consider doing this because the trade-off just seems very much in favor of of doing those changes yeah that makes sense it seems to me that if you're writing software if you're writing uh safety critical software and you're kind of sitting in this boat there's like three different directions it seems like so it's either you just carry on as before and we talked about how you can use MISRA and all of these other tools to achieve a reasonable amount of safety.

Or you could wait until any of those steps in the evolution of C++ come around that we've just talked about that makes C++ itself a safer language. Or I think the third thing you could do is just go and rewrite everything in Rust. Or perhaps, I mean, that's a valid solution, right? For some people.

Or maybe invest into Rust C++ Interop, which isn't very great at the moment. But then that, of course, opens the question, what do you do if you have safe code, but you have to interact with unsafe code? And there's like a can of worms, I guess, that Rust also kind of occasionally has

to deal with. We already have that now. But it's kind of, where do we go from here? We have this big push now to introduce more regulation and we have all these different approaches, we have these different directions, these different possible strategies.

Where should we go? Should we explore all of those things? Does everybody choose what route they're going to go down to? I guess the problem with evolving the C++ language is that the committee is just really slow, tends to be really slow to adapt

such things, especially if it fundamentally changes the design or the direction for c++ it takes like something like a decade to right get something like that through the committee so i think that's perhaps a problem if like the eu and the us is going to introduce regulation perhaps this year exactly and i think it's a little bit unfair to now expect of the committee to resolve all of these issues on their own. That probably won't happen, right? These are really challenging problems. There's a lot of possible solutions, a lot of viable approaches. And I guess the committee will discuss them, and some of them will probably be adopted, others won't, right? But, I mean, the committee as a whole is, like, we are not, like, C++ is not a language that is driven by a single vision, right? We don't have this benevolent dictator for life that just says, this is where we go,

right? It's a collection of individuals. And it changes all the time, right? At no two meetings, you have the same people on the committee, right? It's always in flux. And different people have different requirements. They work in different domains, and they have different ideas for how to solve these problems. So in the end, I think it will necessarily be a combination of approaches.

And depending on who is on the committee, who remains on the committee, we will see what the priorities are that are given to these approaches. If the committee is dominated by people that really care about that last bit of performance and are willing to compromise everything else for that, then getting rid of undefined behavior is going to be tough to argue. But as it seems now, safety is becoming more and more important and so i think there's a good chance that like those those things can get in and if i look at the at the polls that we took at the last meeting in issaquah where we had a full day dedicated to safety and security the committee pretty much said to like all of these approaches that we just discussed, except for rewrite it in Rust.

We said for all of them, yeah, we're basically in favor and we would like to see more of that. Well, the committee is always keen to encourage further work, but as long as it's not a vote about a finished proposal. And once we get to that stage things look quite different exactly yeah but but i think like so i don't think there will be one solution in the end to this to this problem i think it's it's the problem is just too big and too complex for that we will see hopefully see like lots of different proposals uh some small some big I guess in the end, they will have to prove themselves in practice, right? If they can actually solve real problems, if they can give strong safety guarantees to the language, then I think they will be adopted. Even if they don't make it to the

committee, right? If you can write me a checker that can give me guaranteed memory safety, you will find people that will want to use this in practice, right? There's no question there. But we're just not there yet right now, right? We have different ideas floating around. We're not exactly sure which ones of those are going to work and what the trade-offs are, what the implications are for the code that's being written.

So that's something for us to figure out in the coming years. But that's also what makes it exciting, right? That we don't know the answer yet. Yeah, it is still early days, yes. It's going to be interesting to see how it all shakes out i'm a little bit conscious of the time we run quite long but um really wasn't really a discussion that we could we could cut i think so i hope our audience will forgive us but before we do wrap up i did want to just pose one more question to you just moving away a little bit from the whole discussion about

safety and security put the spotlight back on you, Andreas. You give regular conference talks as well. I know last year you were talking about coroutines. I remember us comparing notes at C++ now. And I know you've got a couple of talks coming up this year. Do you want to talk just

fairly briefly? Yeah, I have two talks actually lined up. One is on library API design. So how do you make library APIs that are easy to use correctly and hard to use incorrectly? And how can you leverage the type system to help you there? Nice. And then I have another talk at C++ Now in Aspen

where I actually talk about safety. So it's pretty close to what we talked about today. And the other topics, do they relate to safety? No, actually, usually I like to pick topics that don't relate too closely to my work, or talk about stuff that I stumble across in my free time or that I find interesting or just something that I want to learn more about. Like with coroutines, for example, it was just as I was figuring out how the mechanism

works and going through the pain of figuring it out. I was trying to make a list of all the things that I wish somebody had told me beforehand that would have made the learning experience a lot less painful. And I put all of that in a talk. But in general,

in most of my talks, I don't talk about stuff from my work life, but just topics that interest me in general i can relate to that so you're c++ now in may c++ on c in june and i believe accu in april exactly that's that's correct yeah well that's so cool i'm gonna be at all of those three so we can talk more about c++ yeah or maybe about safety i know about safety yeah but i'll see you at two of them so um we are well over time so is there anything else you want to tell us cinderella before we let you go um just that i i'm really happy that this the safety topic is getting so much attention now. I've been working in this general direction for a couple of years now.

And in the beginning, it's always been tough to get somebody to listen to those concerns that we have in the automotive industry. And I'm really excited that the conversation now is picking up momentum and really excited about a lot of the proposals that we're seeing. Right. Yeah, it is promising. Well, thanks so much for being our guest today and helping to shine the light on safety and security in C++. Is there anywhere that you want to let

people know how to reach you? I think Twitter is still going these days. Yeah, Twitter. I'm not using Twitter that much. Yeah, me neither. I'm on Stack Overflow these days. Yeah, Twitter. I'm not using Twitter that much. Yeah, me neither. I'm on Stack Overflow. Okay. My username there is comicsensms.

So if you find me there, it should have all the info how to contact me. Great. We'll put that in the show notes. All right. Well, thank you so much, Andreas, for being our guest today. And I hope you'll enjoy the show. Thank you so much for

listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if you're discussing the stuff that you're interested in or if you have a suggestion for a topic we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate it if you can follow cpp cast on twitter or mastodon you can also follow me at timur underscore audio on twitter and at timur underscore audio at hacky dam.io on mastodon and phil at phil underscore nash on twitter or at mastodon at phil nash.me on mastodon and of course you can find all of that info and the show notes on the postcard website at cppcast.com.

The theme music for this episode was provided by podcastthemes.com.