Type++ analyzes all application code and infers which classes are ever cast. All of those classes are adapted to include type information (in the form of an RTTI field). All casts are then changed into explicit casts.
As a dialect, some light changes are necessary and we evaluate the amount of code changes --- which are usually small. This gives us type safety for even large programs as evaluated.
Excellent! Do you have any plans to get this feature added into clang or something? How could I use it? If it's in the paper you can just say so. I haven't had time to look at it carefully.
> This inline type field is key for fast and effective type checks for all casts, similar to other type-safe languages (e.g., Java or Rust).
I am not a Java expert but I know enough Rust to detect a problem here. Maybe it just needs clarification?
Rust is often not in fact storing the "inline type field", so presumably they're thinking of some very particular cast and not "all casts". But what cast?
some_f64 as i32 // Nope, that's going to emit code to work out the closest integer
<&str>::try_from(filename).unwrap() // Nope, that's just going to check the filename is UTF-8 encoded
OK, they talk about "down casts" Rust doesn't have inheritance, but presumably they're thinking of e.g how you go from an IpAddr to an Ipv4Addr ? And now at last it makes a little sense, yes we do need to store the difference between v4 and v6 in the data structure. But, what I do not understand is, how can the equivalent C++ (without type++) do anything reasonable here? Why would this be a bug people repeatedly trip? I know C++ is famously the language for footguns, but this is some gets() level stuff if the "no type info YOLO cast" is a thing people actually write.
I think what they are proposing is to replace existing RTTI with their version that actually supports ALL objects, not just directly allocated ones. I assume there is some complex RTTI analysis that goes into determining whether a thing can be cast at runtime, and that check may be omitted if it's not possible to do it. If you pass a stack-allocated variable somewhere by reference, for example, is there any RTTI available on the original object to check a cast? I really don't know.
This is interesting, but it feels like the beginning of a path to nowhere, since it only addresses bad downcasts and none of the other memory safety problems in C/C++. It's totally unclear if the technique they propose could compose with other memory safety techniques to get us to a memory-safe C++.
Also their story about finding allocation sites using static analysis is wishful thinking. There's just too much code out there that does super funky stuff at allocation sites.
And they forgot to cite Fil-C (and Fil-C++), which does achieve full memory safety (and has a complete story for what happens in downcasts). They also forgot to cite a lot of their other competition.
It's a low-cost way to eliminate a whole class of C++ memory usage errors that typically arise at API boundaries. If g++ or clang offered this as a flag, I'd turn it on.
Would you though? You’d pay a cost and you’d still have a dumpster fire of memory safety bugs. Not to mention you’d have to make code changes to be able to use it.
Bad casts account for a minority of memory safety issues. It’ll cost nothing for attackers to look elsewhere. So adopting this will more non zero work for zero gain.
You make it sound like using C++ guarantees memory safety bugs. It most certainly doesn't. Competent C++ programmers don't create many memory safety bugs at all, and consider them easy to fix in general.
[One of the authors here]
Type++ analyzes all application code and infers which classes are ever cast. All of those classes are adapted to include type information (in the form of an RTTI field). All casts are then changed into explicit casts.
As a dialect, some light changes are necessary and we evaluate the amount of code changes --- which are usually small. This gives us type safety for even large programs as evaluated.
A short blog is available here: https://nebelwelt.net/blog/2025/0226-typepp.html
Excellent! Do you have any plans to get this feature added into clang or something? How could I use it? If it's in the paper you can just say so. I haven't had time to look at it carefully.
Our prototype is at https://github.com/HexHive/typepp/ so you can run it in your testing environment
> This inline type field is key for fast and effective type checks for all casts, similar to other type-safe languages (e.g., Java or Rust).
I am not a Java expert but I know enough Rust to detect a problem here. Maybe it just needs clarification?
Rust is often not in fact storing the "inline type field", so presumably they're thinking of some very particular cast and not "all casts". But what cast?
OK, they talk about "down casts" Rust doesn't have inheritance, but presumably they're thinking of e.g how you go from an IpAddr to an Ipv4Addr ? And now at last it makes a little sense, yes we do need to store the difference between v4 and v6 in the data structure. But, what I do not understand is, how can the equivalent C++ (without type++) do anything reasonable here? Why would this be a bug people repeatedly trip? I know C++ is famously the language for footguns, but this is some gets() level stuff if the "no type info YOLO cast" is a thing people actually write.I think what they are proposing is to replace existing RTTI with their version that actually supports ALL objects, not just directly allocated ones. I assume there is some complex RTTI analysis that goes into determining whether a thing can be cast at runtime, and that check may be omitted if it's not possible to do it. If you pass a stack-allocated variable somewhere by reference, for example, is there any RTTI available on the original object to check a cast? I really don't know.
We are forcing RTTI for all classes used in casts, some light code changes are required for this that our compiler will hint at.
This is interesting, but it feels like the beginning of a path to nowhere, since it only addresses bad downcasts and none of the other memory safety problems in C/C++. It's totally unclear if the technique they propose could compose with other memory safety techniques to get us to a memory-safe C++.
Also their story about finding allocation sites using static analysis is wishful thinking. There's just too much code out there that does super funky stuff at allocation sites.
And they forgot to cite Fil-C (and Fil-C++), which does achieve full memory safety (and has a complete story for what happens in downcasts). They also forgot to cite a lot of their other competition.
It's a low-cost way to eliminate a whole class of C++ memory usage errors that typically arise at API boundaries. If g++ or clang offered this as a flag, I'd turn it on.
Would you though? You’d pay a cost and you’d still have a dumpster fire of memory safety bugs. Not to mention you’d have to make code changes to be able to use it.
Yes. Any place that required changes or pragmas because of more restrictive semantics should be a warning lamp.
Sounds like busy work for nothing.
Bad casts account for a minority of memory safety issues. It’ll cost nothing for attackers to look elsewhere. So adopting this will more non zero work for zero gain.
You make it sound like using C++ guarantees memory safety bugs. It most certainly doesn't. Competent C++ programmers don't create many memory safety bugs at all, and consider them easy to fix in general.
Unfortunately they are quite hard to come by, as proven by CVE database.
I am saying that, yeah. Because it’s true.
Like I said, you're wrong.