duneroadrunner

7 ms·

1.
by duneroadrunner 1y ago
So I don't write much C code these days, but I recently encountered strtol() again and am I mistaken or does the interface also violate const correctness? I mean it takes a const char* as the first parameter and then gives you back a
2.
by duneroadrunner 7y ago
Last time I looked at it, c2rust translated from C to unsafe Rust, right? I'll point out a (neglected) project[1] to (partially) auto convert from C to a safe subset of C++. For example, if you need a png encoder/decoder library w
3.
by duneroadrunner 7y ago
At first glance it seems to be similar to boost::safe_numerics. Are there significant differences? https://github.com/boostorg/safe_numerics
4.
by duneroadrunner 7y ago
No, I just read it. SaferCPlusPlus does support all the permission "modes" listed, except the "opaque" one, and transitioning between them (though being stuck with C++'s move semantics). The permissions modes that a
5.
by duneroadrunner 7y ago
> I wrote a post about it.[1] I just read it, and I thought it was great. I had a similar, if perhaps not-as-well-thought-out, reaction to Manish's (I agree, excellent) post. I think SaferCPlusPlus basically implements the permissio
6.
by duneroadrunner 7y ago
> Cone actually does support Rust-like, lifetime-constrained borrowed references Ah, so kind of a super-set of Rust functionality. Presumably these would require a "borrow checker" or equivalent? Is that already implemented? So
7.
by duneroadrunner 7y ago
> I only post to HN to plug my project called SaferCPlusPlus From this account, yes. Too much? Sorry, (you can see) I haven't gotten much feedback. Or is having a separate, project-specific account in itself not cool? > not ever
8.
by duneroadrunner 7y ago
If maximum (or just more) flexibility wrt memory safety is the goal, I might suggest the author take a look at SaferCPlusPlus. In particular, it supports memory safe pointer/references[1][2] that can target objects associated with diff
9.
by duneroadrunner 8y ago
> What guarantees that the "while" loop will not run away and take "data" outside the array bounds? What do you mean "the array bounds"? The code is memory safe. "data" is an iterator that knows ex
10.
by duneroadrunner 8y ago
Thanks for noticing :) It's been quite a while since I worked on the code, but I believe that the translator intentionally left types declared as "char {star}" unmodified assuming that they were being used as strings [1] rath
11.
by duneroadrunner 8y ago
> "Unknown" ranges from 49% to 76%. Yeah, this is interesting. They're saying they can't determine whether a pointer targets an array buffer or not? Perhaps they might want to take a look at the (long neglected) &quot
12.
by duneroadrunner 8y ago
For cases where the platform supports C++ (and its standard library), there is kind of a corresponding "checked C++"[1] that also supports the "completely incremental" migration approach. (And obviously supports "ar
13.
by duneroadrunner 8y ago
Oh yeah, there are plenty of reasons to prefer Rust over C++. I think it's also reasonable to favor Rust's "exclusivity of mutable references" default as a matter of personal preference. I'm just not sure the formal
14.
by duneroadrunner 8y ago
Yes, It's hard to deny the intuitive appeal, but what's notably missing from that blog post, and seemingly any other article about it, is a consideration of the cost/downsides of universal imposition of the "exclusivity
15.
by duneroadrunner 8y ago
Rust's usability is advancing, but I'll note that so are C++'s memory safety facilities. Arguably, modern C++ programming is becoming intrinsically more safe than more traditional coding styles (though arguably the use of st
16.
by duneroadrunner 8y ago
ArrayBufferBuilder isn't, but DOMArrayBuffer seems to be a GC managed type [1], right? And, before the patch, the DOMArrayBuffer held a "refcounting pointer" potentially targeting raw_data_'s reference counted ArrayBuffe
17.
by duneroadrunner 8y ago
Ug. After closer inspection, it looks like those particular raw pointers seem to be managed by a garbage collector. (Specifically, the "Blink GC" [1].) As others have pointed out, this particular bug may not actually be a C++ issu
18.
by duneroadrunner 8y ago
They are working on it. The analogue to the borrow checker in C++ is called the "lifetime profile checker" and (an incomplete version) is included in MS Visual C++, but last time I checked (in January) it seemed to still have too
19.
by duneroadrunner 8y ago
I suggest that the most expedient (cheapest) language to migrate the existing code base to would be a memory safe subset of C++ [1]. In practice most of the safety benefit could be obtained from a just a partial migration. Specifically, jus
20.
by duneroadrunner 8y ago
I'll just mention that if you're using C++, the SaferCPlusPlus library[1] supports a data race safe subset of C++, vaguely analogous to Rust's. [1] shameless plug: https://github.com/duneroadrunner/SaferC
21.
by duneroadrunner 8y ago
Replacing existing unsafe C++ elements with compatible memory safe substitutes[1] might be more expedient. The conversion can even be automated[2] for parts of the code that aren't performance critical. [1] shameless plug: https:&#x2F
22.
by duneroadrunner 8y ago
> it was slower for a dubious benefit Isn't this kind of arguable? The benefit is that it avoids the need to make unnecessary copies in some cases, as is basically acknowledged in the article: > The exclusivity violation can be a
23.
by duneroadrunner 8y ago
Well if you're starting a project now that you expect to live for many years, there's the issue of C++ safety now, and C++ safety in the foreseeable future. Right now projects have the option of building with the santizers (partic
24.
by duneroadrunner 8y ago
Yes, and in C++, linked lists can retain this property and be implemented in a memory safe way using non-owning reference-counting smart pointers[1]. Many defend the use of unsafe Rust in cases like these, in part by asserting that C++ woul
25.
by duneroadrunner 8y ago
Well like I said, if you already have a driver written in C (or C++), translating it to the safe subset of C++ would be less work as most of the code would remain unchanged and the unsafe elements (like pointers, arrays, etc.) map to direct
26.
by duneroadrunner 8y ago
Another option is to use a memory safe subset of C++ [1]. It should be less work to migrate existing C drivers as (reasonable) C code maps directly into the safe C++ subset. And the migration can be done incrementally with corresponding inc
27.
by duneroadrunner 8y ago
equally shameless: https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
28.
by duneroadrunner 8y ago
Yeah, with modern C++, you can largely choose to avoid using elements that are prone to undefined behavior. For example, rather than native integers, you could use a compatible integer class that checks for division by zero [1]. Or one that
29.
by duneroadrunner 8y ago
> I want the standards committee to produce a bounds-checked dialect of C where I can choose to pay some perf cost to get real dynamic and bounds-checked arrays If you don't want to wait on the standards committee, the SaferCPlusPlu
30.
by duneroadrunner 8y ago
> That's not right. You can have a data race to a plain old integer. Sure, if your language allows unprotected access to any object from any thread. Which, I guess traditional C++ essentially does, but presumably a "Safe"

More ›