safercplusplus

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.

> the easiest path to convincingly make C++ safe is to convincingly make C safe first

Yeah, with all the static analysis, I did end up straying from the easy path. Ugh :) But actually, one thing that C++ provides that I found made things easier is destructors. I mean, I provide a couple of raw pointer replacement types that rely on ("transparently wrapped") target objects checking for any (replacement) pointers still targeting them when they get destroyed.

As you indicated in another comment, you explicitly choose to expose/require zalloc() because you didn't want to make malloc() too "magical" (by hiding the indirect type deduction). In that vein, one maybe nice thing about the "safe C++ subset" solution is that it exposes the entirety of the run-time safety mechanisms, in the sense that it's all in the library code and you can even step through it in the debugger. (It also gives you the option to catch any exceptions thrown by said safety mechanisms. You know, if exceptions are your thing. Otherwise you can provide your own custom "fault handling" code (if you want to log the error, or dump the stack or whatever).)

> There's a ton of literature on ways to make C/C++ safe. I think that the only reason why that path isn't being explored more is that it's the "less fun" option - it doesn't involve blue sky thoughts about new hardware or new languages.

I can't think of any other reason that makes sense either. Anyway, the first thing is to dispel the notion that C and C++ cannot be safe, and it seems like your project is likely to be the first to demonstrate it on some staple C libraries. I'm looking forward to it.

Hi pizlonator, I'm working on a solution with similar goals (I think), but a bit of a different approach. It's a tool that auto-translates[1] (reasonable) C code to a memory-safe subset of C++. The goal is to get it reliable enough that it can be simply inserted as an (optional) build step, so that the source code can be maintained in its original form.

I'm under the impression that you're more of a low-level/compiler person, but I suggest that a higher level language like (a memory-safe subset of) C++ actually makes for a more desirable "intermediate representation" language, as it's amenable to maintaining information about the "intent" of the code, which can be helpful for optimization. It also allows programmers to provide manually optimized memory-safe implementations for performance-critical parts of the code.

The memory-safe subset of C++ is somewhat analogous to Rust's in terms of performance and in that it depends on a non-trivial static checker, but it imposes less onerous restrictions than Rust on single-threaded code.

The auto-translation tool already does the non-trivial (optimization) task of determining whether any (raw) pointer is being used as an array iterator or not. But further work to make the resulting code more performance optimal is needed. The task of optimizing a high-level "intermediate representation" language like (memory-safe) C++ is roughly analogous to optimizing lower-level IR languages, but the results should be more effective because you have more information about the original code, right?

I think this project could greatly benefit from the kind of effort you've displayed in yours.

[1]: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

Some solutions aren't that well publicized. Here is an example of an open source png encoder/decoder written in C (mostly) being auto-translated to a memory-safe subset of C++:

https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

If you're planning that far ahead it may not be an either-or situation. That is, in the future C/C++ may also have an enforced memory safe subset. In which case the issue becomes, how do you write your code today so that it will conform to the safe subset? There are conformance tools in the works that can already give you a sense of the restrictions that will be imposed [1].

[1] https://github.com/duneroadrunner/scpptool

Unfortunately, documentation [1] is still kind of lacking. Like Rust (and arguably modern C++ conventions?), the safe subset doesn't support pointer arithmetic directly. You would have to convert the pointer to an iterator (and its target to an appropriate container).

Auto-conversion of code that uses pointer arithmetic is challenging, but has been demonstrated to be solvable in the general case [2].

[1] https://github.com/duneroadrunner/SaferCPlusPlus#getting-sta...

[2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...

I think the answer is yes. There's a complementary project [1] that aims to enforce a slightly more restricted memory safe subset of C++ than the lifetime profile checker does (or eventually will). The restrictions do not manifest as limitations on the code, but rather as extra run-time checks in some scenarios.

The C++ language maps one-to-one to the safe subset, so auto-conversion of (reasonable) existing C++ code to the safe subset should be a straightforward (if tedious) undertaking. The issue will be the performance of the converted code, which will depend on how pointers/references are used in the original code.

Pointers that are expected to never point to (in addition to never dereference to) a destroyed object can be converted to "safe" pointers with little run-time overhead [2]. Otherwise the pointer would need to converted to one with more overhead [3]. Pointers that can be verified (by the static analyzer) to conform to "scope lifetime" rules (akin to Rust) can remain zero-overhead pointers.

New code written in the safe subset would generally have performance in the ballpark of traditional C++ [4].

[1] https://github.com/duneroadrunner/scpptool

[2] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point...

[3] https://github.com/duneroadrunner/SaferCPlusPlus#registered-...

[4] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG... (note that the benchmark code is quite old and will be updated soon)

Counterparts for Rc [1] and Arc [2] (and compiler enforcement of their safe use [3]) are available in C++, though not standard.

[1] https://github.com/duneroadrunner/SaferCPlusPlus#reference-c...

[2] https://github.com/duneroadrunner/SaferCPlusPlus#tasyncshare...

[3] https://github.com/duneroadrunner/scpptool

And also one less thing to transfer to the heads of anyone else that might need/want to understand the code. (Often the author him or herself at some point in the future, right?) Though equivalent facilities are available in C++ [1][2] (and can now/soon be enforced[3]).

[1] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master...

[2] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master...

[3] https://github.com/duneroadrunner/scpptool

Those interested can check out a (nascent) "borrow checker"[1] for enforcement of C++'s memory and data race safe subset.

[1] https://github.com/duneroadrunner/scpptool

While not as mature as Rust, static enforcement of C++'s (memory and data race) safe subset is coming along [1].

Iiuc tools like TrustInSoft are for situations where you need not just safety, but "reliability" (i.e. no crashes, no exceptions). That doesn't really scale so well to larger applications.

[1] https://github.com/duneroadrunner/scpptool

Presumably a C++ (or SaferCPlusPlus[1] ;) implementation would see a similar cache performance advantage versus C?

Also, isn't it unintuitive that branch mispredictions go up with larger batch sizes? Wouldn't there be fewer branches per unit time?

[1] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master...

Others disagree, but I suggest that someone could make such a linter. As others point out, the Core Guidelines "lifetime profile checker"[1] is designed to be an advanced static analyzer that restricts how many C++ elements can be used. It's not finished yet, and the current version is not designed to achieve complete memory safety (and doesn't address data race safety). Whether or not subsequent versions could match the full safety enforcement of Rust's compiler seems to be a matter of some debate.

But there is an alternative/complementary approach, which is to simply avoid potentially unsafe C++ elements, like pointers/references, arrays, std::string_views, std::threads, etc., substituting them with safe, largely compatible replacements[2]. This approach has the benefit that an associated safety-enforcing "linter" would not impose the same kinds of "severe" usage restrictions that the lifetime profile checker (or, say, the Rust compiler) does.

[1] https://devblogs.microsoft.com/cppblog/lifetime-profile-upda...

[2] https://github.com/duneroadrunner/SaferCPlusPlus

edit: grammar

> like a weak pointer that work with unique_ptr, but I do not think it is possible to do this while preserving zero overhead implementation

I think the type of pointer you're asking for basically does exist. First, you want to distinguish the cases when you want a "full featured" weak pointer that can gracefully handle the destruction of its target object [1] (rarely the case), or you just want a non-owning pointer that detects when the prorammer screws up and lets the target object be destroyed prematurely [2].

The latter is essentially just a non-owning reference counting pointer. The optimizer should be able to discard matching increments and decrements of the reference counter in many cases.

> This will have overhead, but it could be worth it for the security gains.

The performance cost of avoiding "unsafe" C++ elements is measurable, but reasonably modest [3].

[1] https://github.com/duneroadrunner/SaferCPlusPlus#registered-...

[2] https://github.com/duneroadrunner/SaferCPlusPlus#norad-point...

[3] https://github.com/duneroadrunner/SaferCPlusPlus-BenchmarksG...