duneroadrunner

9 ms·

31.
by duneroadrunner 8y ago
> It's not clear to me how this is possible without breaking backwards compatibility. What do you mean? Presumably most existing sizable codebases will not satisfy the requirements of the (eventual completed) lifetime checker, even
32.
by duneroadrunner 8y ago
> This proposal and Rust's guarantees are different. A little different, but only in the sense of being, for the moment, less ambitious (than Rust) about the completeness of the checker's implementation. But I think it substant
33.
by duneroadrunner 8y ago
Not sure if it's what you're thinking of, but there is the "C to SaferCPlusPlus" auto-translation helper tool[1]. The idea is that the output can be compiled as straight C, with the safety mechanisms disabled, or with th
34.
by duneroadrunner 8y ago
Pretense not intended, thanks for clarifying. :) Rather than algorithmic novelty, the point is more that ivector has an API and implementation that is memory safe (memory safety seemed to be an emphasis of the blog post). As for those nex
35.
by duneroadrunner 8y ago
> Most of the following blog post is written from a game developer’s perspective, but should also apply to other areas ... Video games are a special case where allocations and deallocations are often well scheduled and predictable. For t
36.
by duneroadrunner 8y ago
Don't forget about SaferCPlusPlus[1]. Much safer than conventional modern C++. Also (optionally) uses scope lifetimes to prevent use-after-free. (Not yet fully compiler enforced like Rust, but hopefully that'll be coming at some p
37.
by duneroadrunner 8y ago
For those that "love C++" (or their existing C++ code base), there's SaferCPlusPlus[1]. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
38.
by duneroadrunner 9y ago
SaferCPlusPlus[1], for example, is a safe subset of C++ that has compatible safe substitutes for C++'s (and therefore C's) unsafe elements. So migrating existing C/C++ code generally just requires replacing variable declarati
39.
by duneroadrunner 9y ago
Yes, documentation and class names are not SaferCPlusPlus' strong points at the moment. Perhaps the easy way to get started is just to use the elements in the "mse::mstd" namespace, like vector, array, string, string_view, et
40.
by duneroadrunner 9y ago
> "guaranteed to be safe" (which will most likely require tooling) rather than merely "safer" - and I will be the first one to promote it myself :-) Well I hope so, as SaferCPlusPlus could use a little promotion :) At
41.
by duneroadrunner 9y ago
If anyone is really interested in this sort of thing, I suggest you take a look at SaferCPlusPlus[1]. It is "A Usable C++ Dialect That Is Safe Against Memory Corruption" (including data races). And it already exists. And I think i
42.
by duneroadrunner 9y ago
> It's technically possible, but retrofitting old code rarely happens. Yeah. A more realistic solution might be auto-translation of existing code. Here[1] is an example that replaces declarations of arrays, and pointers used as arra
43.
by duneroadrunner 9y ago
I'm going to dissent on this. While the Core Guidelines "raise the floor" for code safety, I think the may be lowering/hardening the ceiling[1] as well. One problem is that, they impose an (inflexible) standard for funct
44.
by duneroadrunner 9y ago
> unless you just don't use pointers or references at all (and refrain from using any library that is not safe which includes large parts of the standard library like all the containers) It may seem far fetched, but it might be more
45.
by duneroadrunner 9y ago
Two main components of Rust's approach to memory management are i) the imposing/exploiting of scope lifetimes on objects and references, and ii) the restriction that a mutable reference may not co-exist with any other references (
46.
by duneroadrunner 9y ago
C++ does have a practical, memory-safe subset[1]. Recommended for anyone writing internet facing C++ code. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
47.
by duneroadrunner 9y ago
Here's my hypothesis: The problem with these static verifiers is that they are applied at the wrong stage. The verification logic would be more useful in more cases if it were applied at the optimization stage. Right now the benefits o
48.
by duneroadrunner 9y ago
> good coding conventions in C++ will get you 90% of the way there For those that need it, SaferCPlusPlus conventions will get you even further. > Basically in C++ I think an of old-style pointers/refs as Rust-like "borrowed
49.
by duneroadrunner 9y ago
You mean how it's implemented? Umm, well it's been a while, but basically an ipointer is a proxy for an iterator that is stored internally by the msevector. These "internally stored" iterators are updated when necessary.
50.
by duneroadrunner 9y ago
The problem is that, while in many ways an improvement over traditional coding practice, the subset of C++ associated with the Core Guidelines (GSL stands for "(Core) Guidelines Support Library") has turned out to be a dead-end wh
51.
by duneroadrunner 9y ago
The problem with trying to substitute lists with vectors is that their iterators behave differently. I.e. vector iterators point to positions rather than elements and are prone to being invalidated. So sometimes it's nice to have a vec
52.
by duneroadrunner 9y ago
It's arguably even a little bit nicer in SaferCPlusPlus[1]: template<typename TVectorPointer> void write_foo(TVectorPointer vec_ptr) { (*vec_ptr)[3] += 1; } template<typename TVectorPointer>
53.
by duneroadrunner 9y ago
> basically a nicer C++ with the obvious foot guns removed For those stuck with C++, you're not out of luck in terms of safe and easy sharing between threads. The SaferCPlusPlus library provides "access requesters" that pr
54.
by duneroadrunner 9y ago
> ( http://people.canonical.com/~ubuntu-security/cve/pkg/xmlrpc-... ) It looks like some of those CVEs are dated not that long ago. If code safety is still a concern with this project, you/someone might
55.
by duneroadrunner 9y ago
First let me say that I'm not familiar with Nim. But I understand that it compiles/transpiles to C/C++. And it sounds like they're now trying to move away from dependency on the GC. In that case, might I suggest they con
56.
by duneroadrunner 9y ago
> Does anyone actually want to program in "C++ with instance methods banned"? Well, passing a "safe this" pointer as the first parameter to a (static) member function isn't that hard to get used to, is it? But I
57.
by duneroadrunner 9y ago
> For one thing, the "this" pointer problem is pretty much unsolvable in C++. Well, you could just avoid/prohibit the explicit and implicit use of the "this" pointer. I.e. prohibit non-static member functions[1],
58.
by duneroadrunner 9y ago
> On the other hand, it probably is less effort to rewrite PolarSSL in Rust than doing that proof. It's probably even less effort to convert to SaferCPlusPlus[1] (essentially a memory-safe subset of C++). There's even an tool[2
59.
by duneroadrunner 9y ago
SaferCPlusPlus does not recommend relying directly on mutexes at all. For most straightforward cases, you can use the "access requesters" to safely manage asynchronous access automatically. Recursive mutexes are analogous to havin
60.
by duneroadrunner 9y ago
Yeah, I think it might be a familiarity bias. Anyway, the point of access requesters are that they are much safer than manually protecting resources with mutexes. That is, using access requesters eliminates the possibility of data races[1].

More ›