Thread Reader

Already, we're off to a weird start with these two papers. One of these is a paper title I can get behind and promises some change, the other one makes me want to just close the PDF and go do literally anything else. (Being on Committees has made me opinion-allergic.)

A screenshot of title of C++ paper P2739r0, "A call to action: Think seriously about 'safety'; *then* do something sensible about it".
A much more boring C++ paper p2759r0 titled "DG (Direction Group) Opinion on Safety for ISO C++".
A note that can be missed if you're a serial speed-reader like me: the paper title on the left (the one that sounds like a call to action) actually isn't a call to action. It's an ask to "evaluate the space", and then do something "sensible". If you're a minority, you have heard
the word "sensible" thrown around before. It's usually put up as a way to diffuse a movement for anything better, particularly (in political contexts) by the overarching ruling class. This language implies that "alternatives" are non-"sensible". Bad mouth feel to start.
We'll start with the milquetoast "Opinion on Safety" paper, not out of any principle but because I flipped a coin and lost to myself, so here goes. > DG has unanimously agreed to work on a paper to guide that opinion. We do not aim to define a solution. Alright, ignoring this.
> We aim to define the process ah, here it is. They're just going to set up a bunch of guard rails and possibly get snippy with people who don't stay in those guard rails. Controlling the process but not offering any solutions is fundamental to what Committees do; stack on
effort but don't actually tell anyone what precisely they should be doing. Just tell them you'd maybe sort of kind of like to see something happen in this direction maybe kinda, BUT they reserve the right to take your work and toss it into a volcano. No risk, all reward, weeee.
Getting more directly into the goals, they want to talk about: - safety-by-default, or opt-in, (lol) - safety as part of tooling, or compiler extensions/built-in (lolol) - backwards compatibility (oh boy) - "profiles" (?? not quite properly defined yet)
§2's first paragraph is "C++ is awesome, totes", and like. Okay. "Prior Art" just goes over a (small) fraction of the checkers and linters that exist for C and C++ today (they focus on C++ but let's be real, if you're using C++ you're also interfacing with a LOT of C). ... Wait,
> The use of C++ in these and other applications have really put safety on the map, even though it was already there in some form. ... Uuuhhh. Maybe because it's had so many issues? But I guess anything popular gets lots of issue, but... no? Safety was explicitly a non-goal????
I cannot begin to tell you how many proposals that are safe-by-default or have safety built in get that safety gutted out. It even happened to array-writing overloads in fmt, where Victor Zverovich got bitched at for not being unsafe, and then bitched at again when he changed it!
To say C++ put "safety on the map" is an enormous lie. People were sounding the horn about how unsafe C -- and C++ -- were, and how dangerous they were, for a long time and were not at ALL taken seriously as it was seen as nominally a "research" problem for lots of folk!
§2 and we've already got problems. This paper goes on for another 6 pages.... pray for me. > Both NIST and NSA seem to suggest using an alternate language. Well, now we're at the reason we're writing this paper! Government noticed an awful lot of CVEs from C and C++, and so
they said "stop using C and C++". Makes sense. "It hurts when I do this, Doctor." Then.... stop.... fuckin'.... DOING IT AAAAAAAAAAAAAA. More seriously, people have been screwing up particularly parsing in C and C++ and that's a HUGE part of doing any computer work, period!
The rest of the "motivation" for this is kind of bunk. People have always been asking for well-defined behavior and ways to guard against known problems in C and C++, but we could always go "but yeah it's infeasible". "Autonomous vehicles" are not the reason Safety is SUDDENLY on
the map now, as this paper seems to keep implying. The paper even lists a ton of static analysis tools and checkers; the need has always been there, the Committee routinely ignoring it and pretending like this is a new blossoming thing is pretty disingenuous of it, lmao. NE WAYZ,
the rest of this section is "we responded immediately to the issues we faced by having a LOT of discussion and making a bunch of new groups that are going to give recommendations (and hopefully papers??) that will result in change eventually maybe". Uh. Okay! Hope it works.
Now we're talking about C++'s image, and, woof, > ... they appear especially to satisfy an executive-suite definition of safety ... this is them talking about other languages. You can smell the Mad™ from here, good god. My blog posts are XTRA MAD but not this kinda mad!
"These languages are just projecting an AIR of safe, that satisfies what those crummy executives want but don't understand anything about!" Honestly? Skill issue. You've been in this game 40+ years; if you can't sell things to people as a known Commercial Language... Not Good?
> 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 .... Oh man. Where do I start with this?
An anthropomorphic sheep stares with deep concern, eyes wide and brows nearly perfectly horizontal and furrowed while their mouth is set in a grim straight line. Their hands are clasped together just in front of their chin as they look on, trying to figure out WTF to say HOLY SHIT!!!
Nicolai Josuttis had to pull people's teeth and go around a second time to ask C++ not to wait for some weirdo perfect solution to "function calls and other expressions can leave dangling temporaries in my for loop". I already spoke of Victor, fmt and the array overloads. And,
I have a whole blog post about how std::ranges did not fundamentally improve the safety situation for C or C++ with its algorithms, still only having an output iterator when it could use output ranges to limit the output with NO LOSS OF PERFORMANCE (
And this is just scratching the surface. From standard library bugs in implementations covered by "well it's UB so 🤷‍♂️" (…), to fighting people who want to do things like make stack variables safely init to 0 by default (…), C++ has
Fun fact: the most recent CVE in the Rust standard library (remove_dir_all) also applies to C++ standard library implementations. But in C++ it's just considered undefined behaviour and your own fault if any other process touches the file system, so it's not considered an issue.
always consistently chosen the worst option with respect to safety even if it promised the (illusion) of performance, siding with everyone by safety and safety critical folks who have a long list of complaints. This might be C++ heresy, but RAII is not that huge of a slam dunk!
std::unique_ptr and std::shared_ptr were markedly better, but even code bases that deploy those and use them extensively still have tons of issues. This is not to say people weren't trying when they introduced better RAII tools, but let's be honest; "clean up after myself" is
literally just basic stuff you learn to do when you're a kid and you're given the run-down about how to behave in somebody else's house, or what you're supposed to do when you're a big enough kid to take your own plate to the dishwasher or sink. It's literally the baseline!
(C, being the language it is, doesn't even have that baseline yet.) Which gets us back to this paper; a LOT of it is touting its improvements over what is effectively old C++ and mediocre / normal C code. And that's fine! But comparing yourself to the worst isn't exactly a Win.
Either way, I digressed too far.) All this to say C++ has an enormous amount of improvements left to make. So, what're the guiding principles for success? The paper has ideas: > So how do we succeed? We strongly believe that we succeed by doing what we think is best
> for the language, not simply by copying some other languages. We succeed by learning from others and drive a process that facilitates this evolution of C++ towards better safety support. We succeed by not ignoring other domains. 2023, we're going to stop ignoring folks? Neat!
> … We believe we should not force safety on everyone, especially those who don’t need or want it. Safety should not be static, but evolving... Gotta have something to evolve it, just. Just FYI. Granted, they have some; but there's a lot pointed out in just this thread, and
a lot of what I pointed out is *known* stuff, not brand new crap we still have yet to figure out. It's really hard talking about 2023 problems if you still haven't fixed 2003 problems, but at least we're openly talking about it in major proposal now?
Anyways, we're finally past §2. It's §3 time - "Basic Tenets". These are the things they don't want us to change. (Screenshot because it's too long to tweet it all.) Some of these are actually a little bit in conflict with one another!
● do not radically break backwards compatibility – compatibility is a key feature and strength of
C++ compared to more modern and more fashionable languages.
● do not deliver safety at the cost of inability to express the abstractions that are a pillar of C++
● do not leave us with a “safe” subset of C that eliminates C++’s productivity advantages.
● must not are purely run-time and thus impose overheads that eliminates C++’s strengths in the
area of performance.
● should not imply that there is exactly one form of “safety” that must be adopted by all.
● do not hold the promise of delivering complete guaranteed type-and-resource safety.
● do not offer paths to gradual and partial adoption – opening paths to improving the billions of
lines of existing C++ code.
● must not imply a freeze on further development of C++ in other directions.
● must not imply that code written in different environments with the same types have different
For example, "opening paths to improving the billions of lines of existing C++ code" conflicts deeply with "do not radically break backwards compatibility". The whole point of C++ (and C) is that you can write some code and -- no matter how awful -- it will keep on working. If
an idiom is recognized as dangerous or similar, you have 2 choices: - deprecate that and work towards a solution, - introduce lots of new stuff to cover the old space, but with better alternatives. We are historically bad at the 2nd bit, and the first bit invalidates old code,
BUT even if you focus on the 2nd bit at some point you have to recognize that in order for that code to change, you need to "offer paths to gradual and partial adoption" so that the old code can be fixed where needed, but that quoted sentence is just after the words "DO NOT", so.
"Opening paths" necessarily means gradual and partial adoption. You can't open a path that nobody walks: the purpose of a system is what it does, and if you have a beautiful cobblestone walkway that literally nothing travels down you just have a fancy modernist art piece, not a
practical, well-used walkway. So at some point you're going to have to do something with all that lovely backwards-compatible (but potentially increasingly vulnerable) code and give them something **to do gradual and partial adoption with**. So yeah, the basic tenets are weird!
Another weird one: > do not leave us with a “safe” subset of C that eliminates C++’s productivity advantages. ... Yeah dude I don't think you're going to get a ""safe"" subset of C anytime soon. My old tweets are deleted but I've literally live-critiqued linux mailing lists and
other articles where people put pie-in-the-sky "if we just static analyze C harder we can make it safe" and just. ... No, lmfao. Also, from the people who tried to make "safe C subset", I present to you "C and C++ are really late to their own party, part 400 / ♾":
A screenshot off of the Cyclone Webpage (, stating:

Cyclone is a safe dialect of C.

Cyclone is like C: it has pointers and pointer arithmetic, structs, arrays, goto, manual memory management, and C’s preprocessor and syntax.

Cyclone adds features such as pattern matching, algebraic datatypes, exceptions, region-based memory management, and optional garbage collection.

Cyclone is safe: pure Cyclone programs are not vulnerable to a wide class of bugs that plague C programs: buffer overflows, format string attacks, double free bugs, dangling pointer accesses, etc.

Cyclone is no longer supported; the core research project has finished and the developers have moved on to other things. (Several of Cyclone's ideas have made their way into Rust.) Cyclone's code can be made to work with some effort, but it will not build out of the box on modern (64 bit) platforms).
> Our proposed solution is as follows .... Wait I thought we weren't doing solutions in this document??? Or maybe this is the "guardrails" part we all keep talking about. So maybe they're about to hit us with a bunch of guard rails and boxes they expect the solution to be in.
> - aim at a framework which is noticeable publicly - place safety changes within that framework - agree on where we make those changes (tools, language), - agree on backward compatibility - prioritize the most important items to focus our attention on "framework" uh oh...
Out of §3. We're on §4 now, "The process". It's a short section, it just says "yeah so actually Study Groups" (the small, sub-units beneath the Committee) "are really terrible at figuring stuff out and get bogged down so we need to provide some direction". ... So §5 is them
offering direction. I guess we're going to finally get to the meat of the paper now? The nitty gritty? §5 is "Towards a safer future" so it's bound to get some meaty ideas in here. How will it go?
> We now support the idea that the changes for safety need to be not just in tooling, but visible in the language/compiler, and library. HOLY SHIT IF THEY REMOVED EVERYTHING ELSE IN THIS PAPER AND JUST PUT THIS SENTENCE IN AND SIGNED ALL THEIR NAMES THAT WOULD BE IT, PACK IT IN!
Like, you all DO NOT understand how VICIOUSLY the compilers and implementers were guarded from having to take responsibility for the shit the language pulled. Every single time it was "let tools do that" or "static analysis will fix it". THIS IS THE FIRST ADMISSION THAT THE
> We believe it should be visible such that the Safe code section can be named (possibly using profiles), and can mix with normal code. Individual features may not be very visible, but will be more visible when packaged. "Rust has unsafe{}, we should have safe{}!" Awh geez.
They won't likely name it "safe {}", and as the paper goes on to explain this is where the idea of "profiles" come into play. Named profiles will provide a way to effectively say "for this block / function / (however they spell it), these rules are in effect". Opt-in. Bad idea.
After "const", "[[nodiscard]]", and the millions of other C++ failures to pick the right default, they're just gonna go ahead and keep putting money into that sunk cost. Hilarious. I guess it's just what C and C++ do at this point. You always gotta mark the right way...
But, well, and this is where things get really weird... > We see various profiles can appear in source code that potentially automatically trigger analysis. We do not restrict profiles just for safety, but could also support performance, embedded, or other aspects. Mmmmmmnn....
I just hope we all remember OpenGL, core vs. compatibility, ES versus non-ES, and all the bullshit that implied. How it broke the industry into pieces. How it turned a decent graphics specification into "Write Once, Debug On Every Single Platform Get To It You Li'l Bitch", and...
The Direction Group is just recommending we do that, all over again. But not just locally in like a Graphics API, but GLOBALLY in EVERY SINGLE C++ CODE BASE EVER, and also everyone gets to FIGHT EACH OTHER AND PICK DIFFERENT NAMES, so not just core vs. compat, but like
"embedded" versus "freestanding" versus "mobile" versus "safety-medical" versus "safety-aviation" and just. Haha, people are already complaining about complexity, and your idea is to introduce the most hair-brained complexity scheme of all time? Brave. Very, VERY brave.
> Profiles impose restrictions on use where they are activated. They do not change the semantics of a valid program. Oh man, it's Attributes but rather than having (mostly local) effects, it's Global Attributes But Even Worse. I'd be laughing if it wasn't crying, good GRIEF.
That's the end of §5 now. §6 starts like this: > Let's assume WG21 agrees on this as a framework for moving forward… lmfao. Good fuckin' luck. There is literally only one quote in this document worth reading, in that they acknowledge the language/library has a role in safety.
You can safely ignore the rest of the paper as noise, and you can definitely ignore these guard rails. I'm not sure how they got to this solution or who's advising them, but it's a bad idea that's not just theoretically bad, but proven-bad over decades of "profile"-based code.
(Not just OpenGL, but C tried this. Remember "embedded C" versus "safe C" versus "Holy C" and like the 200 existing dialects of C and how they all promise a lot but have anemic implementation effort? Yeah. This is that, on bloody steroids. Christ on a bike.)
fighting tooth and nail to get a better Freestanding language and standard library. C++'s profiles CANNOT be a "just a valid program with some better rules" because we can't even get the proper rules that ALREADY exist in the standard.
Björkus "Fix It Or Die Trying" Dorkus
The C Standard Cannot Be Replaced And Will Never Be Destroyed. ➡ | Avatar @WusdisWusdat
Follow on Twitter
Missing some tweets in this thread? Or failed to load images or videos? You can try to .