safercplusplus

7 ms·

1.
by safercplusplus 2mo ago
Hmm, I'm not sure if you're concerned about the "norad"-style run-time checked references I'm imagining or raw references. In either case, the property we (and `Pin<>`) are concerned about is whether an object
2.
by safercplusplus 2mo ago
Ok, I guess somebody has to provide the youngsters/uninitiated with some context. What is going on here can be viewed as part of a process of Rust (potentially) incrementally adopting the C++ model, because the Rust model is limited in
3.
by safercplusplus 2mo ago
Well, there is another safe option for flexible pointers if you can compile as C++ [1]. In C++ you can have non-owning "smart" pointers with run-time-checked lifetimes [2][3]. Importantly, there is no run-time overhead to derefere
4.
by safercplusplus 2mo ago
If the concern is memory safety, I'd invite comparison with migration to the scpptool-enforced memory-safe subset of C++ [1]. If your C++ code is "idiomatic modern" C++, then the changes required to conform to the safe subset
5.
by safercplusplus 2mo ago
But are we necessarily limited to native integer types? At least with C++, the type system is powerful enough to support integer replacement types (eg. [0][1]) that don't inherit these issues. (Where, for example, the subtraction of an
6.
by safercplusplus 4mo ago
If the source language is C++, another option might be to use AI agents to port to a memory-safe subset of C++ [1]. For the most part, this involves surgical changes and glorified find-and-replace operations. And I'm guessing way fewer
7.
by safercplusplus 4mo ago
You might be interested in the scpptool feature to help convert C code to a subset of C that will also compile as C++ (under clang++ at least) [1]. While many of the necessary modifications are fairly trivial, some of them aren't compl
8.
by safercplusplus 5mo ago
> It's in many cases as simple as renaming a file from .c to .cpp. That is rather optimistic, but, for example, scpptool has a feature [1] that auto-converts from C to a subset of C that can (hopefully) be compiled with clang++. If
9.
by safercplusplus 5mo ago
I think the concern is that the writing may be on the wall for (the current memory-unsafe version of) Coreutils. Despite the bugs and incompatibilities, Canonical seems to have decided that the memory safety of uutils is worth it. And those
10.
by safercplusplus 5mo ago
I don't know if you're aware, but there is a demonstration of wget (a fellow "gnu utility", right?) being auto-translated to a memory-safe subset of C++ [1]. Because the translation essentially does a one-for-one substit
11.
by safercplusplus 7mo ago
Interestingly, I recently auto-translated wget from C to a memory-safe subset of C++ [1], which involves the intermediate step of auto-converting from C to the subset of C that will also compile under clang++. You end up with a bunch of cla
12.
by safercplusplus 7mo ago
And I might suggest that there's the possibility that the C++ code could end up being more cleanly ported to a memory-safe subset of C++. plug: https://github.com/duneroadrunner/scpptool/blob/master/
13.
by safercplusplus 7mo ago
Plug: In theory you could auto-convert to a memory-safe subset of C++ as a build step. Auto-converted code would have some run-time overhead, but you can mark any performance-sensitive parts of the code to be exempt from conversion. And you
14.
by safercplusplus 1y ago
As long as we're plugging our projects, I'll mention the scpptool-enforced memory-safe subset of C++. Fil-C would be generally more practical, more compatible and more expedient, but the scpptool-enforced subset of C++ is more dir
15.
by safercplusplus 1y ago
> Profiles cannot achieve the same level of safety as Rust So the claim is that the scpptool approach[1] can, while remaining closer to traditional C++, and not requiring the introduction of new language elements. Since the scpptool-enfo
16.
by safercplusplus 1y ago
> From what I'm aware of, Rust has poor ergonomics for programs that have non-hierarchical ownership model (ie. not representable by trees) Yeah, non-hierarchical references don't really lend themselves to static safety enforce
17.
by safercplusplus 1y ago
Yeah, but C++ now supports "user-defined" annotations which effectively allow you to add the equivalent of any keyword you need, right? (Even if it's not the prettiest syntax.) For example, the scpptool static analyzer suppor
18.
by safercplusplus 1y ago
Right. And of course there are still less-performance-sensitive C/C++ applications (curl, postfix, git, etc.) that could have memory-safe release versions. But the point is also to dispel the conventional wisdom that C/C++ is nece
19.
by safercplusplus 1y ago
A couple of solutions in development (but already usable) that more effectively address UB: i) "Fil-C is a fanatically compatible memory-safe implementation of C and C++. Lots of software compiles and runs with Fil-C with zero or minim
20.
by safercplusplus 1y ago
Might I suggest that the scpptool-enforced safe subset of C++ has a better solution for such data structures with cyclic or complex reference graphs, which is run-time checked non-owning pointers [1] that impose no restrictions on how or wh
21.
by safercplusplus 1y ago
Makes sense. But maybe the fact that that post is 4 years old serves to bolster the argument for Fil-C's value proposition. However much people may want to move away from their C code bases, the resources it takes to do so in a timely
22.
by safercplusplus 1y ago
Preach it brother! :) Hmm, I take it that the situation is that there are a number of vendors/providers/distros/repos who could be distributing your memory-safe builds, but are currently still distributing unsafe builds? I wo
23.
by safercplusplus 1y ago
This particular memory vulnerability, as I understand it, was a result of a `ReadonlySpan<>` targeting a resizable vector. A simple technique used by the scpptool-enforced safe subset of C++ to address this situation is to temporarily
24.
by safercplusplus 2y ago
Thanks for clarifying. The issue is what code would be rejected for auto-translation, not the correctness of an "accepted" translation (as my comment may have implied). The point of noting that the example translation quietly does
25.
by safercplusplus 2y ago
And even then, not completely reliably it seems (from Section 2.2): > The coercions introduced by conversion rules can however lead to subtle semantic differences The example they give is this C code: 1 uint8_t x[1] = { 0 }; 2
26.
by safercplusplus 2y ago
You might consider experimenting with the scpptool-enforced safe subset of C++ (my project). It should be even less disruptive. [1] https://github.com/duneroadrunner/scpptool
27.
by safercplusplus 2y ago
In theory it could be auto-converted to a safe subset of C++ [1]. In theory it could be done at build-time, like the sanitizers. [1] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
28.
by safercplusplus 2y ago
Hey thanks for your support! Committee interest might be nice, but I think what would be most helpful at this point is just additional resources in general, whether as a result of committee interest or otherwise. :) Here's a feature co
29.
by safercplusplus 2y 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 i
30.
by safercplusplus 2y 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, presum

More ›