SaferCPlusPlus

Rust may ultimately be the better solution for many or most cases, but right now SaferCPlusPlus[1] may be the more expedient solution for existing C/C++ code bases. > Any time your code takes in untrusted input, it should not be written in an unsafe language. Not just that, but my theory is that untrusted input should only be stored in data types specifically designed for untrusted input [2], and should undergo safety/sanity checks during conversion to more high-performance types. For example, a general rule might be that untrusted integer inputs may only be converted to (high-performance) native integers if their value is less than the square root of the max integer value. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus#quarantined...

You know, while C++ references are technically unsafe, there is TRegisteredRefWrapper<> [1]. It's a safe version of std::reference_wrapper. Which kind of acts like a reference. So, if you don't mind me using std::strings instead of doubles, your example could be rewritten like mse::mstd::vector<mse::TRegisteredObj<std::string>> data(10); data[0] = "some text"; mse::TRegisteredRefWrapper<std::string> dangling = data[0]; data.resize(100000); try { std::string crashing = dangling; } catch (...) { // expected exception (not a segfault) int q = 3; } Does that work for you? I'm not an expert on std::reference_wrapper, so I'm not sure when it can and cannot substitute for a reference. (Btw, if it's a little verbose for you, there are shorter aliases available. Just search for "shorter aliases" in t

> and so I'm stuck with C++ If you're stuck with C++, might as well do it safely: (shameless plug) https://github.com/duneroadrunner/SaferCPlusPlus

Yes, after reading a draft[1] of this document, I suggested to them that they seemed to be insufficiently emphasizing remote execution vulnerabilities (due to invalid memory access). I also pointed out that they neglected to mention Rust and the Clang/LLVM sanitizers. (And SaferCPlusPlus[2] too.) They acknowledged my comments, but it doesn't seem to have had much effect on the document. [1] https://news.ycombinator.com/item?id=12643463 [2] shamelss plug: https://github.com/duneroadrunner/SaferCPlusPlus

Yup. SaferCPlusPlus has vector and array substitutes that will also catch "use-after-free" bugs and use of invalid iterators. Clang/LLVM and gcc also provide "sanitizers" with much more comprehensive checking. But there are still situations when you'd want to use SaferCPlusPlus [1]. [1] https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp...

Well, since they seem to be including collections of elements, each with dependency on one or two files, SaferCPlusPlus[1] could be added to the "data structures" category. It's a collection of safe compatible substitutes for C/C++'s unsafe elements that's generally intended to be used as a whole, but certainly supports cherry picking of individual elements. For example, you could choose to use its safe substitutes for std::vector (and std::array) while foregoing its safe pointer substitutes. The implementation design was a trade-off between minimizing redundancy and minimizing dependencies (and inter-dependencies). Ultimately I decided minimal dependencies would be more appealing to the user. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

But that argument doesn't necessarily call for a new language, it only calls for the prohibition of the unsafe elements of the existing language. Intuitively one might assume that potentially unsafe elements (like pointers, references, parts of the standard library, etc.) are so ingrained in C++ that prohibiting them would cripple the language. But actually, C++'s preprocessor is powerful enough that instead of abandoning those potentially unsafe elements, you can instead replace them with safe compatible substitutes. SaferCPlusPlus[1] is a collection of such substitutes. And since the substitute elements are themselves pure C++, you can still use your existing IDEs, debugging tools and SDKs. And the migration of existing code can be done completely incrementally, and much of it won't need to be changed at all. [1] shameless plug: https:/

While conventional C++ is a vast improvement in memory safety, it does not, at the moment, fully address the problem. Complete memory safety may be achieved if/when the "Core Guidelines Lifetime Checker"[1] is completed, but in the mean time SaferCPlusPlus[2] can be used to achieve memory safety. SaferCPlusPlus can, of course, be used with C code as well (if you're willing to use a C++ compiler), but will typically be slower than with the corresponding C++ code. [1] https://blogs.msdn.microsoft.com/vcblog/2016/03/31/c-core-gu... [2] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

> But others point out that explicit lifetime annotation is not required to evaluate memory safety [3]. I think you've extrapolated a bit too much from that answer: the code still has to be semantically lifetime-correct, even if the annotations don't need to exist syntactically. Code that wasn't written with Rust-style lifetimes in mind (even if they're not literally written in the code) is unlikely to automatically satisfy the rules statically, so unless SaferCPlusPlus is using a custom compiler that runs Rust-like rules on the code and flags violations, I would expect a lot of such code is only dynamically correct. > [2] https://github.com/duneroadrunner/SaferCPlusPlus#safercplusp.... A few points: - what do you mean by rebindable and non-rebindable references? That is not terminology Rust uses at all, and so it isn't clear what this i

For the author: You might consider using SaferCPlusPlus[1] as an intermediate step. Most C code translates easily (and automatably if you're already parsing the C code) into SaferCPlusPlus. This already gives you memory safety, if that is the goal. Next, you can translate to "rustesque" SaferCPlusPlus. SaferCPlusPlus provides elements (pointer types) that (loosely) correspond to Rust elements [2]. The borrow checker's rule of "mutable reference exclusivity" would have to be additionally self-imposed. As you know, this is the hard (difficult to automate) part, but the nice thing is that even partially completed translations/rustifications would remain fully functional (and memory safe). The idea is that "rustified" SaferCPlusPlus code should translate to Rust fairly easily. There seems to be some skepticism of the notion of a "rusty" C/C++

> Yes, it's fast, but at what cost? I would gladly give up a massive fraction of my performance for better security and portability - and that's why I program Java. While I agree with the sentiment, a problem with Java is that you're dependent on a runtime environment with a fairly consistent history of vulnerabilities, right? [0][1] > Personal opinion here, but with few exceptions C/C++ are inappropriate languages for starting new development at this point. Maybe, but now there's SaferCPlusPlus [2]. At least it may be a practical option for improving memory safety in many existing code bases. [0] http://www.cvedetails.com/product/19117/Oracle-JRE.html?vend... [1] http://www.cvedetails.com/product/1526/SUN-JRE.html?vendor_i... [2] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

Another choice is SaferCPlusPlus[1] (optionally with a framework like Wt[2]). Using a higher level language (than C) arguably has the drawback of "hiding complexity" in exchange for better productivity and scalability. But languages like Rust and C++ (with SaferCPlusPlus) retain much of the intrinsic performance and memory efficiency of C, without introducing an additional runtime layer. That may allow you to employ extra (diverse) layers of sandboxing/jailing and other security/correctness solutions. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus [2] https://www.webtoolkit.eu/wt

If you're considering switching to Rust for code/memory safety reasons, SaferCPlusPlus[1] may be an easier/cheaper/low risk option. It allows you to add memory safety to your existing code base in a completely incremental way, with no dependency risk. (At the moment, standard library support is required though.) [1] https://github.com/duneroadrunner/SaferCPlusPlus

> it's as fast as C++ these days And C++ is as safe as Java these days. [1] I wonder which claim is more optimistic. :) [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

> Merely being safer than c++ is enjoyable because I don't have to be quite so paranoid about introducing bugs. For those times when you have to use C++, SaferCPlusPlus[1] should help. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus