C++ Club - WG21 January mailing, safety, contracts

Episode Date: February 9, 2023

With Bjarne Stroustrup, Gianluca Delfino, Vladimír Arnošt and other colleagues.Video: https://youtu.be/uONoChyos_MNotes: https://cppclub.uk/meetings/2023/158/

Welcome everyone. This is meeting 158 and today is 26th of January 2023. A bit of feedback. Paul Floyd emailed me, quote, in a latest podcast you talked about values that get used to fill memory like ate bad food. You also mentioned OXAA. This gets used a lot in memory tests since it's 1010 in binary. So by writing AA then 55, which is 0101 in binary, you can try to test if there are any problems with neighboring bits toggling. CppCast news. The CppCast podcast has new hosts timo dumler and phil nash best of luck to them with the revived cpp cast uh this is an intro of the revived podcast with the former hosts,

Rob Irving and Jason Turner as guests, which was weird to listen to. It's very good as usual. There was some interesting tidbits. Jason said that the proposed safety features like zero initialization of locals make sense only for those who don't use any tools since the current compiler and static analysis tools let you know when you use uninitialized variables. And Timur mentioned something called erroneous behavior which is not undefined behavior but is still an error.

It would allow the tools to detect it but would also prevent exploits. The problem with that is that such behavior can't be expressed in the C++ abstract machine. So that's something for the committee to decide on, I guess. Is there any example of such erroneous behavior? Not that I remember from the podcast. Maybe like use of termove or something like that? Don't know. It's like not UB. I mean, UB makes it possible to detect such violations by say UB sanitizer.

If it's not UB, then you can't detect it at runtime. So this would be something like mostly a mistake but technically allowed or something that is definitely mistaken and is definitely wrong? No, it would be definitely an error. But it wouldn't be UB at runtime. Okay. So I guess static analysis could deal with it.

Interesting. Now, let's see what was in the January mailing. There is a Reddit discussion and lots of polls listed. There was a question someone asked, what's the status on reflection? And the reply was, is the committee still reflecting on it? There is an active discussion regarding the proposed default zero initialization of variables and some notable documents. The first one we are going to look at is Bjarne's paper called A Call to Action. Think Seriously About Safety, Then Do Something Sensible About It.

There are lively discussions of this paper on both Hacker News and Reddit. Regarding that NSA memo that calls for abandoning C++ or C slash C++ as they call it, Bjarne says this quote that specifically and explicitly excludes C and C++ as unsafe. As it's far too common, it lumps C and C++ into the single category C slash C++, ignoring 30 years of progress. Unfortunately, much C++ use is also stuck in the distant past, ignoring improvements, including ways of dramatically improving safety." End quote. By the way, there is another memo that's just appeared, and this time it's from Consumer Reports. It also talks about

memory safety and also mentions C and C++, but it's either c or c slash c++. I couldn't see any mentions of c++ as a separate language. Rust mentions are a plenty. It's more than a little annoying. I also couldn't see any c++ experts in the list of contributors. This document raises valid points, but pushes heavily memory-safe languages like Rust. There was an interesting thread of discussion on Hacker News. And this person on Hacker News writes, after all, statistics just isn't on his side, meaning Vianey. Even the top engineers hired by Google create around one memory error every thousand lines and they didn't have one yet in 1.5 million lines of rust. This is with all of the analysis

tools at their disposal and in use for C++. And most companies can't afford the same top talent that Google can. And the article linked is about memory-safe languages in Android. This prompted several people to respond with some pushback. This one writes, If you want to use statistics to support your assertion that C++ hasn't gotten better, with some pushback. This one writes, If you want to use statistics to support your assertion that C++ hasn't gotten better, safer, and more efficient over the decades, then your statistics must compare different versions of C++, not C++ and Rust.

The blog you link to is a PR piece, but that's not the major issue. You're taking as a fact that Google's Android C++ programmers are particularly interested in safety or are significantly more competent than average. Based on my occasional perusal of Android C++ code in a professional context, I cannot confirm either assumption. Android C++ is not modern, not even C++11 modern, and is very pointer heavy. It's an eclectic mix of C functions and C data types with C++ constructs. That is the C with classes to me, they say. And there were more comments

telling things like Google's end user software is pretty poor, the Google C++ guidelines are notoriously old-fashioned, and they have tons of legacy code, even in projects like Chromium, that are basically C with classes, so are very prone to errors that modern C++ is more robust against. There's lots of interesting comments on Reddit. And comparing the two discussions, I would say that Reddit seems not better, but not as inflammatory, I'd say. Calmer discussion. Maybe I'm wrong.

Maybe we are biased because this is the CPP subreddit and so it's partial to be more lenient towards any C++. And there was instead Hacker News, which is more open to everybody to bash on C++, which has become a popular sport, I think. Indeed. Another quote from Bjarne's paper. In general, he talks about static analysis, mentioning Visual Studio core guidelines, analysis profile,

and Client ID. Hang on, let me admit people. Oh, Bjarne is joining. Hi Bjarne. Hi. We were just talking about your paper. I see. We were looking at some discussions about that, including the one on Hacker News and Reddit. that including the one on hacker news and reddit and we looked at how hacker news says

there was a quote let me repeat it um someone says after all statistics just in isn't on his side meaning you even the top engineers hired by google create around one memory error every 1000 lines. And they didn't have one yet in 1.5 million lines of Rust. And someone replies in the vein that the article they linked about memory safe languages in Android codebase is a PR piece. And Google Android code, C++ code, is notoriously bad in the sense that it's very pointer-heavy and it's not even C++11 modern. It's basically C with classes. So that's not a fair comparison.

It may not surprise you, but I'm not too impressed by the comments I see on the web. As usual, many people, possibly most people, doesn't seem to have read the papers. And there's claims like, of course you can't prove the safety of just static analysis. And of course you can't. Everybody should know that. So therefore, we're not proposing it. You were mentioning the NSA paper.

There is another paper regarding the memory, C++ memory safety, this time from Consumer Reports. I don't know if you've seen it. I've seen it. And it also uses C slash C++. Yeah. A very popular mythical language which combines the errors of both, problems of both, when described. So I was going to quote your paper a little, and the quote was, of both when described. So I was going to quote your paper a little,

and the quote was, what might something sensible to do be? I suggest making a list of issues that could be considered safety issues, including UB, and finding ways of preventing them with the framework of your previous paper. That's what I plan to do." And the next paper we were going to look at was this one, a direction group opinion on

safety for ISOC++. This is by Howard Hinnant, Roger Orr, Janus Stroustrup, David Vandewoorde and Michael Wong. And to me, this looks like a meta-paper proposing a process and a framework for further security work. Quote, C++ appears, at least in public image, less competitive than other languages in regards to safety. This seems true especially when compared to languages that advertise themselves more heavily, actively, brazenly, competently than C++. In some ways, they appear especially to satisfy an executive suite definition of safety, which makes it attractive for executives to ask for a switch from C++. Yet what has been lost in the noise is that C++ has made

great strides in recent years in matters of dangling resource and memory safety. Newer languages have less vulnerabilities because they have not been through the test of time. Today even Rust, in all caps, has had vulnerabilities discovered recently and time will expose more vulnerabilities and weaknesses for general use. Aha! Take that, Rust! This dig at Rust, while likely fair, doesn't look very good, to be honest. The paper proposes something called profiles. Quote.

To support more than one notion of safety, we need to be able to name them. We call a collection of restrictions and requirements that defines a property to be enforced, a profile. A typical profile will not be a simple subset of language features. And we like to think profiles do not fragment the ecosystem but increase diversity. For example, we might even have safety profiles for safe embedded, safe automotive, safe medical, performance games, performance HPC and EU government regulation. Profiles impose restrictions on use where they are activated. They do not change the semantics of a valid program.

In particular, a piece of code means the same in every profile or no profiles. This property is the crucial difference between dialects and our approach." This reminded me a bit to what Jared Waterloo proposed in his paper C++ is the next C++, where he proposed static analysis attributes, turning some analysis on and off. The more relevant comment is the profiles in Core Guidelines and the paper by Gabby and me on the variety of safety notions. Oh, that was the design alternative for type and resource safety plus plus, right? Yes, yeah. I'm firmly convinced that you cannot get this kind of safety simply by

subsetting. You need the combination of static analysis, then you need rules to simplify the use of the language to the point where static analysis works. And you then need libraries to simplify the way you write the code so that you don't have to get into the dark corners all the time. Is there a suggested syntax to impose such profiles, like namespace or something? This is a bit up in the air, but Gabi and I are suggesting annotations in modules. The real deeper problem of all of this is that take anything you call safe. It'll be called by something that isn't, and it'll call something that isn't, or the same definition of safety, if it is part of a really large system as opposed to a standalone. And so you now have to deal with the issue of how you get in and out of safe modules or whatever you call them,

and how you interact between different kinds of safety. If you have a type safe thing that includes this range checking, how do you call a module that only does range checking but doesn't validate pointers and vice versa? That whole set of problems. And that appears in every interlanguage system. I've seen Scala programs getting null exception errors and things like that. And I've seen Java crashes because they were calling C.

Yeah. By the way, also, there is a whole other side of the conversation where they quote how safe is Rust, but a lot of the time they compare against a section of the C++ that if they would replace, they would have to use unsafe. So a lot of those statistics that say how good is Rust completely ignored the fact the part of that Rust language where you would actually need unsafe and therefore you're

basically using something analogous. They forget you must credit anybody who has increased degree of safety with the fact that there's a smaller set of things that needs to be checked and a smaller attack surface. One of the things that you do with something like core guidelines, if you actually enforce their use, would be that the number of places you'd have to look for a problem decreases dramatically. Like you won't have to look for dangling pointers anymore. This again would be true for all languages. If they don't have unsafe trusted sections they'll call a language that doesn't do those checks like C or C++. I also saw an interesting point someone raised that many C++ programs are not directly expressible in Rust because of the safety features that prevent certain concepts from even being implemented. So you either have to hit unsafe Rust or do it in C++.

Sure. And this is going to be the case in every safe language for every definition of safe and every definition of language. At the beginning, we did mention a CPP cast that got revived, fortunately, with the new hosts, Timo Dummler and Phil Nash. And in their intro episode, Timo mentioned something called erroneous behavior in the context of safety improvements, which is not undefined behavior, but is still considered an error and which could possibly be discussed in the committee. And it presumably would allow the tools to detect it, but wouldn't cause any exploits at runtime.

But the problem seems to be that such behavior can't be expressed in the C++ abstract machine or something. Do you know anything about it, Bjarne? Not enough. I do know that undefined behavior is a big problem. If you can do time travel optimizations, a lot of bits are off. And this will be discussed at some point. It must be.

There's lots of feedback for the direction group paper on the internet and not all of it is good. Henry Sivanin on Mastodon says it makes it look like the C++ leadership is not up to the task of engaging with the issue of memory safety in a credible way. and my impression is that you're damned if you do and you're damned if you don't whatever paper you write or don't um it will be considered wrong by people, by some people. Sure. Quite often considered wrong by people whose only test was, does he agree with what I think? And if not, it's deemed incompetent. Yeah. Not everybody on that extreme, but the loudest voices very often,

well, gets the most time it seems to me that at this point we're fighting against gut feelings and emotions so on one side there could be as much logic as you want but the other side is always answering with you know yes but that's not my feeling. So Rust is better or something. A couple of years ago, there was a review that something like 90% thought Rust was the best language ever and 2% of voters had tried it. Presumably, the statistics are better now, but still, people will express opinions on things they don't know anything about.

Yeah. It looks like this drive for improved safety and all these papers that say C++ is bad resulted in many people forming their opinion. And whatever the C++ committee does, it's now considered by those people as sort of, what do you call it, damage control. And he's instantly dismissed. The way people think.

Let's see, we launched the core guidelines more than seven years ago. I wrote the JSF++ guidelines about 20 years ago. We didn't actually start yesterday. Well, the attention is peaking at the moment to this issue. So many people, I guess, are only now discovering what's been happening and often dismissing the stuff that's been done before this. Yeah, and very often they are looking for very simple solutions. One simple solution that will solve all their problems. They are, of course, not going to find it. The solution I'm sort of suggesting, the area area of solution rests on three legs. Static analysis, library,

and coding rules. People don't like that. That's complicated. It's not one thing. It's not just something you can clock in and get a solution out of. Yeah. Next paper we were going to look at was Gabi Dosseray's Contracts for C++ Prioritizing Safety. This paper got updated, there were slides posted and the paper now has an inset with the main idea at the top. Quote, this document suggests a design of contract predicates that emphasizes safety by default by reducing opportunities for undefined behaviors in contracts and their propagation across abstraction boundaries. An accommodation in the form of relaxed contract predicates is provided for scenarios where safety by default is not a primary concern.

End quote. And the goal is, another quote, Consequently, a viable contract system for C++, however minimal, must ensure that the evaluation of a contract predicate cannot itself be an exploitable source of undefined behavior by compiler optimizers. Hence, it's about time travel and the need to look into QP. Some more notable quotes from the paper. It is also an answer to the call to action for improving safety in C++ programs. Jan Estrostrup's paper that we just talked about.

Yeah, notice Gabi is co-author to the paper about the different kinds of safety and how to deal with it, the profile stuff and such. Right. Quote, in practice, contracts are summaries of the expectations and guarantees of a successful function call.

As such, not every single action taken or statement written in the body of a function implementation needs to be reflected in the expression of the contracts of a function. The ideal that the contract

predicates design presented in this paper aims for is, the evaluation of contract predicates shall be free of undefined behavior and they shall not modify parameters they reference. Contracts provide basic mitigation framework, they should not themselves be sources of vulnerabilities. We should aim to reduce defined behavior from contracts as much as possible. This proposal modifies the current minimal viable proposal as follows. Categorize contracts into two groups. First, non- relaxeded contracts. And second, relaxed contracts. There is a whole section on UB in the paper.

And the proposed solution is, quote, tighten the specification of the C++ abstract machine so that contract predicates evaluation never invokes undefined behavior, even if other parts might, and appropriately restrict the contract predicate language. Regarding side effects in contract expression, Gabi says, quote, I suggest that we make each of a precondition and a postcondition a self-contained expression, their free variables being function parameters and constants, and side-effects

free, when seen from the outside of each of their cone of evaluation. Gabi introduces a new concept of conveyor function. Quote, a conveyor function is conceptually a function that when called with an argument list performs no side-effects outside of its function body or argument list. Furthermore, such a function does not perform any operation the behavior of which might invoke undefined behavior. A conveyor function is declared

with the attribute conveyor and its body is subject to syntactic restrictions as defined below in the document." Is it what they call a pure or referentially transparent function with extra security features and restrictions to prevent UB? I suspect so, but I have not read this version of the paper, so I don't have any opinion on it. It is always unsafe to ignore Gabi. The appendix of this paper contains answers to the questions raised after presenting the initial version of the paper and collated in the other document that we discussed previously,

the questions on this one. Unfortunately, the questions are not copied into this paper, so you need to have both papers open to see the questions together with the answers. Yes, those are the questions that are in the other mailing list entry, including also a lot of others. Herb Sutter, I've seen that one in the listing. Yeah, I think so. Lots of questions. It was not a coherent set. It was a union of lots of people's questions.

And so they went all over the place. It's hard to answer such a set of questions each extensively because well they make different assumptions and they refer to different versions of things it's quite hard so i can see why he wouldn't copy it again and also that questions paper is, the entire paper is just questions. So to copy it would be duplicating the entire paper. It was a reunion of whatever people were interested in or confused about. But judging from the appendix, I think Gabi diligently answered all the questions that were in that paper. He certainly tried, I know. And at the very end of this paper, Gabi included a quote by Chuck D,

which goes like this, quote, It is not a matter of skills, but a battle of wills. I can't help thinking it's about the committee. Oh dear. The other relevant paper is by Andrzej Krzymanski. Contract predicates that are not predicates. I think it's about side effects in contract expressions. Things like whether or not the program should be marked ill-formed if a contract predicate cannot be proven to be referentially transparent. So it's like other solutions

to side effects are proposed in parallel together with Gabi's version. And the next one is proposal of simple contract side effect semantics. Quote, we propose and motivate a set of simple intuitive and time-honored semantics for side effects in MVP contracts. In essence, we propose that contract expressions have the same side effect semantics and evaluation semantics as any other C++ expression. So they say side effects are allowed, I think. Yeah, I think this paper arguments with an example where there is a robot that may need to check if it's standing correctly before performing a motion of some sort and this may call a whole machine learning pipeline and log and do other things and all those logins and machine learning and calling to external sensors would eventually have side effects. So just to check if the robot is in the right position before performing some action

necessarily would imply that we need to allow for side effects. The question is, is that really what you want to be a predicate in a contract? Or is that a program you want to be a predicate in a contract? Or is that a program you want to check? I don't think everything should be embedded in contracts. You mean maybe we should prohibit behavior like logging in a contract because that's something that... I didn't say that. I did not say that.

I'm just saying that extreme examples like launching a rocket to tell me whether there's a Chinese space station on the back side

may be a reasonable thing to do if you are the right kind of organization, but it would be really strange to put it into a contract. When you don't get the absolute, everything or nothing, you have to find a boundary, and that's always hard. And I'm not going to suggest one right here but these two are sort of the opposite this one and Gabby is saying exactly the opposite things basically I guess at some point when you are writing or thinking about writing a contract predicate and putting more and more stuff into it at some point you have to stop and think

is it still a contract predicate or a separate like function so i noticed that this paper seems to be also based on the notion that contracts are either not evaluated or evaluated with program termination on failure which is going to be unacceptable for a large number of applications. Like I have a paper saying that. Exactly. Do I understand correctly that none of the proposals anyway are allowing for contracts to be disabled at release?

Like, for instance, in assertions. All of those contracts implementations or suggestions they implicitly leave those, whatever is the implementation of the contract in a release build, I think. Is this correct? I think there's controls so that you could switch to, say, compile time only checks. But there has been changes, and I'm not fully up on all of the changes that has happened. So you'll have to read something more carefully to know the answer to that one.

Thank you. This was not the only paper that mentioned these two options of not checking or crashing, terminating on fault. There was a vote in that study group some time ago for a roadmap, which they keep referring to. And that roadmap claims that what they have is a minimal viable solution. Some people claim it's neither minimal nor viable. Oh and they're saying that in that MVP those two are going to be the only options. Yes and if you want something else you can always propose it later. Right. So, next paper by the same author, Andrew Tomaszos, introduces another third style of contract expressions.

Quote, We propose coining a new term called an in-condition. If a precondition is a condition that must be true at the entry of a function, and a postcondition is a condition that must be true at the exit of a function, an in-condition is a condition that must be true at a point within or inside a function. End quote. It used to be called assertion. It's not assertion because assertion doesn't rhyme.

No, really. I get it. Quote. Much the same as postcondition, incondition is not an English word and does not appear in the dictionary. That's a good justification, isn't it? Do you think we can get a feature in Codex KCD? Yeah, and to my medically educated mind it sounds like a symptom. Sorry, we should not ridicule. Well since we're inventing new words now I propose mid condition instead because why not.

And there's more apparently. It also proposes to truncate these new non-words to pre-cond, in-cond, and post-cond, because we don't have enough of awkward keywords in C++. What's the date of this paper? The 4th of December last year. But it's revision zero and that was the January mailing was the first mailing that I saw it in. So the next one is by Joshua Byrne and it's called evaluation of checked contract checking annotations. Quote, we propose a series of rules to govern the evaluation of predicates and thus to determine whether contract violation has occurred. What I noticed was that this also dealt with the two modes only, nor eval and eval underbought.

It's a very tidy proposal with very clearly denoted paragraphs that list the actual proposed features. Quote, When the predicate of a checked contract checking annotation would have undefined behavior, a defect occurs. Platforms are encouraged to treat any such UB as a contract violation occurring. End quote. I'm not sure how that would work. Compilers would have to detect UB, which is not always possible. I wish it was, but yes, by definition.

And by the way, you would have to know whether the UB occurred in something called from a contract predicate. So you have the same function called from a contract predicate and from elsewhere, the UB would have to be dealt with differently. Messing with the abstract machine may be necessary, but it's certainly not easy. Yes, the next one is reconsidering concepts in place syntax.

And this revives one of the terse notations of concepts that were proposed by Herb Sutter. The one with the curly braces enclosing the type identifier. And it proposes a modification for this with a colon,

auto colon T instead of auto curly T. Why? Because very often you need a name type. They want to use the name. Oh yeah, if you say auto x... Or rather you want to say t. Because yes, because then you can like forward use a std forward with the type and so on but what's uh why is it better with the colon instead of with the braces uh well the braces were rejected as far as i can remember

so why not try colon i don't know um if if only we had a proposal to simplify concept syntax, which was also rejected. No, I can't remember. Bjarne, can you remember? Oh, I was thinking about something else. Sorry. Syntax debates are really very productive. Since I haven't carefully looked at that paper, I carefully don't have an opinion

about it. Fair enough. This paper by Dietmar Kuhl of Bloomberg is called Sender-Receiver Interface for Networking. And I think it's a noble endeavor to use centers receivers to define a networking architecture. It raises hopes in me of a standard networking solution based on the standard asynchronous patterns. And I'm sure it'll do just fine in the committee. Well, we'll see. Certainly, some of us have hoped that you could put SEO on top of central receiver and get on with that.

But it's very complicated. Each time we get near, new ideas seem to be coming along. And so it doesn't terminate. Right. The next one is interesting. Adding the new SI prefixes. And it's interesting to me because I learned four new words. Quote, we propose to add the missing SI prefixes.

Coecto tend to the power of minus 30, ronto, 10 to the power of minus 27, as well as rona, 10 to the power of 27, and queta, 10 to the power of 30, to the ratio header. So, yeah, interesting. Are they in? ratio here so yeah interesting are they international which context are these words using usually never heard those myself wait there's a reference right there in the first sentence so some international organization have added those names to the standard ones

and so this is basically a paper that says, well, if there's a new international standard for naming, we should use it. I'm curious what the binary prefixes are going to be, Ronnie, Quinty, or what kind of abominations? There is no way to know. I wonder if these things are really actually used in the real world. I mean, you do know that some standards aren't actually used. I think I asked a physicist friend of mine. Or maybe I need an astrophysicist for these numbers. Oh yeah, maybe they're used in cosmology. The big ones tend to be in cosmology and the little ones in particle physics.

Yeah. Unless we are in those fields and write code in those fields, I don't think we should express an opinion. My humble opinion, I think most physicists and cosmologists, they like using just numbers like 10 to the 30 or 10 to the minus 30. But, you know, maybe I've been out of the game too long to know. I've certainly

heard counterexamples. That is, I agree that I hear numbers more often than the names of numbers, but I have heard counterexamples, people actually using names. I stopped at Femto. That was, you know, the smallest

I remember. I wonder if Rust has equivalent names for these kinds of things. Could be a definite C++ advantage if it doesn't. Next, we have a paper by Aaron Bowman, which is called CXOR C++ programming. Quote, is it not uncommon to hear about C slash C++ programming as a shorthand for C and C++ programming? This implies that C and C++ are similar, but distinct programming languages with the obvious interpretation being that C++ is a proper superset of C. However, this does not accurately

describe the situation. This document enumerates instances where the same source code has different meaning when compiled with C and C++ implementations." End quote. I wrote a paper about that in 2002. All old is new again. This was a very interesting paper to me that presented many differences between C and C++ that I didn't know about, together with very convenient Godbolt links. So all these snippets

you can try yourself on Godbolt. And a related link, if you really want to do something in C but you are a C++ developer. This is a Modern C for C++ peeps article which says right away Modern C is not a subset of C++ and then goes to explain how to do C. Right, I think that's it for today and I will leave you this quote by Brian Kernighan. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. End quote.

That's a famous quote. Thank you very much for joining me. I'll speak to you soon. Bye.