Viewing profile — safercplusplus

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 concerne…

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 adopt…

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]. Impo…

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 c…

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 t…

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 …

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 modi…

> 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 …

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 dec…

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 translatio…

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 wil…

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/sc…

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-sensi…

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, b…

> 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 intro…

> 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 …

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…

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…

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 s…

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-…

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 c…

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 cur…

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 subs…

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 o…