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

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.

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.

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.