Scpptool – a tool to enforce a memory and data race safe subset of C++

https://github.com/duneroadrunner/scpptool

by coffeeaddict1 • 2 years ago

53 10 2 years ago

rurban• 2 years ago

I just tried it out. Still needs debugging CODE, lots of IF_DEBUG code, crashes with -DNDEBUG.

Yeah. The provided build script produces a DEBUG executable (only). The NDEBUG version isn't tested regularly yet. But performance isn't really an issue, so the NDEBUG version has sort of been de-prioritized in favor of feature completion. The fact that it crashes at all in any mode is generally concerning (and a little ironic for this tool), but the crashes are generally due to the use of the (libtooling) clang library. Its (not-super-well-documented) interface seems to be designed for maximum speed, not safety. And I've found that some of the perhaps lesser used elements (including some used for static analysis) are just buggy, and the bugs sometimes change from version to version. But yeah, the tool is not yet in a well-tested or polished state. But I figure, even in a not-well-tested state it can only improve the safety of the code it analyzes/enforces. I mean, even if any bugs or shortcomings in the tool prevent it being able to fully achieve the design goal of ensuring that the analyzed code is completely safe, in any case it shouldn't result in the analyzed code being any less safe than without it, right?

p.s.: Despite complaining about and trying to deflect blame on the clang library, of course it is an amazing library without which none of this would be practically doable.

p.p.s.: Please don't hesitate to post any problems you encounter as an issue in the repository.

p.p.p.s.: At this point, volume is low enough that any feedback at all is welcomed as an issue in the repository.

p.p.p.p.s.: I didn't post this item. I was rather surprised to stumble upon it this morning.

coffeeaddict1• 2 years ago

I didn't post this item. I was rather surprised to stumble upon it this morning.

Hey, I posted this because I've been following your repo for quite a while. Together with Circle's borrow checker and Cpp2, I think this is a promising approach to make C++ safer although I wish the committee would be more involved in these sort of experiments (something that probably won't happen anytime soon).

safercplusplus4• 2 years ago

So I'll turn my attention toward addressing some of the crashing/reliability that I've been neglecting. If anyone is finding it an issue right now, it may be better in the next few days or weeks. Again, feel free to post an issue in the repository if you're running into something specific you want addressed.

cozzyd• 2 years ago

I don't know why an uncapitalized makefile irks me so (even though apparently GNU make will read makefile before Makefile).

comex• 2 years ago

Some pretty… interesting… naming conventions. One of the types is called:

    mse::rsv::TXSLTACSSSXSTERandomAccessIterator

What to make of this? The readme provides this guidance:

The "CSSSXSTE" part of the typenames stands for "Contiguous Sequence, Static Structure, XSLTA, Type-Erased".

But it nowhere defines XSLTA. With some help from ChatGPT, I can guess that "XS" stands for "execution scope" (since the readme talks a lot about execution scopes), and "LTA" probably stands for "lifetime annotated" (since one part says that "rsv::TXSLTAOwnerPointer<> is a 'lifetime annotated' version of TXScopeOwnerPointer<>").

But what about the namespaces, "mse" and "rsv"? I can find nothing to explain what those might stand for.

Anyway.

I really like the idea of this project. There are contexts where I cannot use Rust and would love to have a way equivalent safety guarantees in C++. Even at the cost of rewriting the code. And even at the cost of ugly code, because there will be some necessary ugliness when retrofitting lifetimes into C++'s existing syntax and semantics.

But "TXSLTACSSSXSTERandomAccessIterator" is unnecessary ugliness. There are better ways to get ideas across than acronym soup.

There are some other practical issues with the project, such as inconsistent licensing annotations, and the fact that it seems to depend on specific Clang versions (and thus will probably bitrot if it stops being maintained).

Still, it seems promising and I may use it someday.

safercplusplus4• 2 years ago

You figured out all the letters of the acronym. I'm kinda impressed :) I should probably state it in the documentation, but I made the names kinda comically verbose and ugly to imply that, while these names will always be valid, presumably shorter nicer aliases will be more commonly used. Choosing nice names isn't really part of my skill set. I may be subconsciously hoping the user community will at some point come up with a set of nicer aliases that will just be adopted as de facto standard :)

"rsv" stands for "requires static verification" (to ensure safety). A lot of elements in the library get their safety enforcement via the type system and aren't really dependent on an analyzer like scpptool for their safety. The ones that are generally go in the "rsv" namespace.

I can't remember what "mse" stands for right now. I'm pretty sure the "s" stands for "safe" or "safety". At one point, and possibly still, the idea was to support entities maintaining their own version of the library if they wanted (to completely eliminate dependency risk). In that case one might want to change all the "mse" namespace references to their own namespace name. scpptool is coded to allow you to specify the base namespace of your version of the library.

There are some other practical issues with the project, such as inconsistent licensing annotations

Any licensing issue is just me being careless/lazy I assume. I don't intend for there to be any restrictions. I think I just tried to make everything original to the project use the boost license, which seems totally permissive to me. If I need to do something to fix the licenses, let me know.

the fact that it seems to depend on specific Clang versions (and thus will probably bitrot if it stops being maintained)

The only reason there is any dependency on clang version is because the clang libraries keep making breaking changes on successive versions. It used to be really bad, but these days they're generally minor breakages. At this point if someone doesn't want to wait to update the version of clang that scpptool uses, it's pretty much just a matter of doing a search-and-replace for the version number in the build script and makefile, and then fixing whatever annoying thing the new version broke. A lot of times it's them slightly reorganizing the (large) set of clang libraries scpptool needs to build against (which requires modifying the makefile). One of the goals of this project is to be as small of a dependency risk as possible. I think it compares favorably to some of the alternative solutions in that regard.

Scpptool – a tool to enforce a memory and data race safe subset of C++

Related Stories