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…
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…
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…
> 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…
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…
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…
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…
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/appro...
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…
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++…
> 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…
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…
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…
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…
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…
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…
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…
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…
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…
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] = {…
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
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...
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. :)…
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…
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…
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…
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…
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…
> 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…
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…
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…
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…
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/appro...
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…
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++…
> 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…
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…
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…
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…
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…
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…
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…
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…
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…
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] = {…
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
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...
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. :)…
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…
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…