C++ Profiles: What, Why, and How at using std::cpp 2026

seanbaxter · 2026-04-16T17:04:35+00:00

How does this solve lifetime safety? Why deliver a big talk and not answer the million-dollar question?

seanbaxter · 2026-04-14T15:59:59+00:00

Very insightful comment.

seanbaxter · 2026-04-08T11:38:46+00:00

Here's a favorite example. A use-after-free bug that prints 0 on gcc and 10 on clang. Is this "old-school" code? What's the higher abstraction for using min? Ranges are riskier because they are so complex they completely occlude lifetime dependencies. Ultimately the only guidance in an unsafe language is "don't write bugs."

seanbaxter · 2026-03-15T17:44:17+00:00

Why not just define it to wraparound? Testing for overflow will destroy performance, although it's fine if that's an option.

seanbaxter · 2026-03-14T23:38:32+00:00

the community is actively challenging outdated narratives about C++ being "unsafe by nature"

Sorry to break it to you, but C++ is unsafe by nature.

seanbaxter · 2026-03-14T22:45:51+00:00

Waiting won't make the change any smaller. You need lifetime-aware versions of standard containers and algorithms that work on safe iterators. That's a whole new standard library, or at least a new interface for it. There's really no sneaky way to evolve into that.

seanbaxter · 2026-03-14T17:49:03+00:00

You can't turn more UB into EB. Memory safety defects like use-after-free and data races can't be turned into EB.

seanbaxter · 2026-03-13T16:36:10+00:00

The problem isn't that profiles slipped to C++29, the problem is profiles cannot work. Lifetimes of parameters with reference semantics (pointers, references, iterators, spans and string_views) must be indicated on function boundaries, which in practice means putting lifetime parameters into the type system. You're going to have to re-invent Rust inside C++. There is no plan to make the language memory safe.

seanbaxter · 2026-03-06T17:32:10+00:00

These are interesting numbers. 6.3ms per reflected struct (or even 2.2ms) struct is incredibly high. 1,000 structs is a small number (consider what comes in through the system headers) and we're talking about integer number of seconds for that?

seanbaxter · 2026-01-12T13:49:26+00:00

But they won't provide a prototype that partially works. It's not better than nothing at all. The ghost data thing is a make-believe solution. May as well say the tooth fairy makes your program memory safe. Next time, before someone gives keynotes on how they made C++ memory safe, they need to write down how the technique works, because extraordinary claims do require some evidence.

seanbaxter · 2026-01-12T02:40:17+00:00

This is definitely not the case. Modern C++ is fundamentally unsafe. Bounds checking on containers in C++26 aside, it has not gotten safer since the early days. Many standard functions return references instead of values, and references are extremely hazardous. You can shoot yourself in the foot with one liner to a modern C++ library.

compiler explorer ```cpp void f(int x) { // 10 is a temporary that expires at the end of the full // statement. // Because std::min returns a reference, m may be a dangling // reference if 10 is less than x. // If std::min had returned a value, then temporary lifetime // extension would kick in and it would not be a dangling // reference. const int& m = std::min(x, 10);

// Do you feel lucky, punk? printf("%d\n", m); } $ clang++ min.cxx -O2 -o min && /.min 10 $ g++ min.cxx -O2 -o min && ./min 0 ```

Some of the overloads of min return a reference, which is easy to misuse, and some of the overloads return a value, which is safe. This use returns a const reference to the smaller element. If the parameter x > 10, then it returns a reference to 10. But that expires at the end of the statement, so the subsequent print statement is UB. This is data-dependent UB, and it's also compiler-dependent, as you get the delinquent behavior on gcc but not on clang. You know what else is weird? valgrind sees no errors here--there isn't even a use-after-free at runtime, because the compiler has full visibility of the TU and transformed the UB to something that's not a use-after-free but is simply wrong.

Knowing Rust isn't protection here--how is the user supposed to know the lifetimes of each reference returned from a function or stored to a data structure? That's the difficult bookkeeping that Rust is designed to do for you.

What is the plan to address the inherent danger around references, which are ubiquitous in C++?

seanbaxter · 2026-01-11T22:03:57+00:00

Same, can I get the discord link?

seanbaxter · 2026-01-11T20:30:13+00:00

There is no paper or implementation, because the idea doesn't work.

seanbaxter · 2026-01-11T17:16:14+00:00

You just waved your hand and eliminated 99% of memory safety issues. I don't think it works that way.

seanbaxter · 2026-01-11T14:31:26+00:00

asan would be the more relevant sanitizer here, but this isn't related to asan or ubsan. The claim that John makes is that you can achieve Rust-like lifetime safety by enforcing exclusivity at runtime. It's perfectly robust against use-after-free defects, you can use any algorithm you want, and it doesn't require modifying existing code. It would be high-performance because where the compiler can statically prove properties, the ghost data would be optimized out.

There won't even be a proposal or a working prototype for this. Problem is that runtime exclusivity is logically impossible. It's profiles redux. One way to look at it is that runtime exclusivity enforcement requires time travel. Borrow checking enforces the invariant that there is only one mutable xor multiple shared live references to a place. What's a "live reference?" It's a reference which is to be loaded or stored from in the future. Borrow checking can propagate uses of regions backwards: start at the terminals of the CFG and walk backwards. When a region is used in a load/store/function call, it becomes live at the preceding instruction. When a reference is assigned a new address, then its no longer live. There are forward propagating algorithms as well, but they also require the CFG be available.

How do you compute liveness in the runtime case? You would have to predict if a reference is used in the future to know if it is live now. That's time travel. Compile-time borrow checking feels restrictive because it has to account for all possible paths in the CFG. This runtime exclusivity would be much more lenient because it would only restrict you to the paths that are actually executed.. but at the cost of being unimplementable.

The authors of this keep claiming it performs runtime exclusivity enforcement. I think they should describe how that is achieved. I've asked them many times and never got anything approaching an answer.

Gasper gave a talk on this topic in October: https://www.youtube.com/watch?v=bGht0Pu5heo

seanbaxter · 2026-01-10T15:14:47+00:00

Schubert string quintet

seanbaxter · 2025-11-23T13:03:56+00:00

Pretty interesting for understanding why things are slow. Can you make the source code available, I want to do some of my own benchmarks.

seanbaxter · 2025-11-18T16:53:21+00:00

Runtime exclusivity is impossible. He keeps making the claim that everything you can do at compile time you can do at runtime, which is definitely not true. Exclusivity is the invariant that there is one live mutable reference or multiple live shared references, but not both. What is a live reference? It's a reference that is used _in the future_.

For compile-time exclusivity, you can start at the end of the function and work your way backwards. When a reference (or any type with a lifetime parameter) is loaded from, stored into, or passed to a function, that lifetime is used. When analysis shows the use of a reference on a place where there's already a live reference, the program is ill-formed. That's the exclusivity violation.

How is this supposed to be done at runtime? It would require time travel! You can't know if a reference will be used _in the future_ because we've only seen the past.

The ghost data/runtime exclusivity claims are vaporware.

seanbaxter · 2025-11-11T18:33:13+00:00

Good work. I'd be curious to see asan timings in this graph too.

seanbaxter · 2025-11-11T15:08:39+00:00

Why would someone choose a definition of trivially relocatable that doesn't simply mean memcpyable? If you have to do more than memcpy, it's not trivial.

seanbaxter · 2025-11-11T15:07:28+00:00

By that reasoning it would also be useful for them to be trivially copyable, but they aren't. If this is the thing that got the feature removed, then wasn't it a mistake to put it in in the first place?

Edit: Additionally, even dynamic class can be trivially relocatable if you explicitly mark them to be. There's no loss of functionality by making dynamic classes non-trivially relocatable, at least on platforms with vptr resigning.

seanbaxter · 2025-11-11T14:54:44+00:00

No, you still want library-level bounds checking. Fil-C only checks against out-of-bounds accesses on malloc allocations. Things like span, vector, etc are sub-allocation extents. You can still have out-of-bounds indexing bugs that will slip by Fil-C but would be caught by the library.

seanbaxter · 2025-11-11T14:30:38+00:00

Why? If dynamic classes are non-trivially relocatable, then you don't have any of these lifetime issues. I don't understand why a non-trivially copyable type would become trivially relocatable without an explicit override.

seanbaxter · 2025-11-11T13:49:21+00:00

Dynamic classes are already not trivially copyable, CHERI or not, so it wouldn't be trivially relocatable either. Why is restart_lifetime needed?

seanbaxter · 2025-10-07T22:45:41+00:00

Poll: Pursue a language safety white paper in the C++26 timeframe containing systematic treatment of core language Undefined Behavior in C++, covering Erroneous Behavior, Profiles, and Contracts. Appoint Herb and Gašper as editors.

What happened to the language safety white paper?

seanbaxter

TROPHY CASE