[dead]
Zig: Pointer Stability for ArrayLists
51–60 of 91 posts
Re: Zig: Pointer Stability for ArrayLists
#52This seems weak. In a language like Rust, the compiler will “lock” the pointers for you, and you can’t forget. In a language like C++ (and presumably Zig), one could, in theory at least, have the iterators and slices that reference the storage of a dynamic array hold some sort of lock that pins the storage. But this API requires the programmer to remember to lock the pointers and also requires the programmer to keep…
Do any languages have a notion of "relative pointers"? So in the example if instead of appending "line" as ptr & len, it'd instead be appending an offset & len which could in theory be used to safely compute the actual location even with relocations.
Not exactly what you asked, but c++ does this for vtables if you pass the right option to the compiler: -fexperimental-relative-c++-abi-vtables
There is a similar proposal for trait objects in rust.
Re: Zig: Pointer Stability for ArrayLists
#53Aside: one Zig (syntax) feature that I really missed in Rust is shown in the second code block, namely prefixed multi-line string literals à la: const text = \\This is a long comment \\But I can split it among lines arbitrarily \\And keep my indentation. ; I've started using the Rust macro library `docstr` [1], which does the same thing: const TEXT: &'static str = docstr!( /// Now I can do it in Rust, too. /// I pref…
C# solves this so elegantly
string text = """
This is a long comment
But I can split it
And keep my indentation.
""";Re: Zig: Pointer Stability for ArrayLists
#54Earlier quoted context omitted.
> With Rust, when I need such control (which is always, otherwise I would use a higher-level language), I need to give up safety, anyway, at which point I have no safety and the complexity of a language that offers safety. This is a very, very, very common claim. And unfortunately I have no other way to describe it other than a strawman. In 95% (at least) of the application that need systems programming (not to talk…
[flagged]
I'm not super certain you're interested in answers, but assuming good faith:
> https://github.com/rust-lang/rust/blob/main/library/core/src... How large a percentage of the logic code there is inside of an unsafe block?
The claim isn't "there's no unsafe". You've linked one file out of an entire stdlib; it uses unsafe to implement its algorithm, and of all the Rust code that could exist, this has one of the highest requirements for being maximally performant.
Now if you'd said "most of the Rust std library is unsafe", or "most Rust code is unsafe, you'd have a good rebuttal. But that's not the case.
> And, if you have an unsafe block that is 100% correct, but it relies on safe code being correct, do you need to vet all that safe code? Potentially whole modules needing to be vetted?
Then the unsafe block is not 100% correct. I can slap a wrapper around memcpy and call it "safe", and say that if anyone passes wrong parameters it's their fault. Rust as a language says I'm at fault for saying it's safe though.
> Is unsafe Rust code generally harder to get correct than code in other languages, due to...
Harder than other systems programming languages? Having worked in a fair few, I disagree. Harder than "higher" level languages? Some of them yes, some of them no; I've seen "simple" languages admit very poor architectures, and fall in a "safe" heap when the project has to grow.
> Do Rust libraries, including std, historically have had UB bugs? https://materialize.com/blog/rust-concurrency-bug-unbounded-...
Are you suggesting this is a bar a language should achieve? Some examples of this would be interesting.
As for the rest, I don't think anything meets this bar you're setting. Certainly not languages that would otherwise be used where Rust is.
Re: Zig: Pointer Stability for ArrayLists
#55C++ developers constantly wrestle with `vector` iterator invalidations. Good on Zig for making this a first-class concern.
How does Rust avoid this?
Re: Zig: Pointer Stability for ArrayLists
#56C++ developers constantly wrestle with `vector` iterator invalidations. Good on Zig for making this a first-class concern.
How does Rust avoid this?
In rust you cannot mutate anything that is being read basically. The borrow checker enforces this.
So an iterator takes an immutable reference to the vector and mutation requires a mut ref, and you can't have both at the same time.
Re: Zig: Pointer Stability for ArrayLists
#57Earlier quoted context omitted.
> With Rust, when I need such control (which is always, otherwise I would use a higher-level language), I need to give up safety, anyway, at which point I have no safety and the complexity of a language that offers safety. This is a very, very, very common claim. And unfortunately I have no other way to describe it other than a strawman. In 95% (at least) of the application that need systems programming (not to talk…
[flagged]
Yes you need to vet touching safe code. Which is why you keep things private, encapsulate them, and extract them into reusable crates.
The most important reason unsafe code is harder to write than C or C++ is that you must keep soundness, something none of these languages have. But yes the different rules also play part (although: do you know a single C or C++ codebase that does not violate TBAA? Some just disable it in the compiler, making them non-standard, while some just leave it potentially exploitable).
But the most important answer is the empirical evidence like I brought above. We have empirical evidence C and C++ codebases cannot be secure. We have empirical evidence Rust codebases can, even with unsafe code. Therefore, Rust is safer, period.
> Do Rust libraries, including std, historically have had UB bugs?
Did C or C++ libraries, historically, have UB bugs? Sorry, that just amplifies the strawman.
> Can Miri catch everything?
Miri is a dynamic analyzer, aka. a sanitizer. It will catch anything you test. It's like in C and C++, except you only need it for unsafe code.
> Are all the rules of unsafe, pinning, etc. fully specified and easy to learn and reason about?
Fully specified? People are working on it (are C's and C++'s UB rules fully specified? I'll save you the answer: no. Yes there is a standard and it's woefully incomplete).
Easy to learn and reason about? Probably not, which is why not everyone should be writing unsafe code.
Possible to learn and reason about? Absolutely yes. Especially with existing and emerging dynamic and static analyzers.
Re: Zig: Pointer Stability for ArrayLists
#58Earlier quoted context omitted.
That is called an index. If you want it to be standalone, you can bundle it with the ArrayList.
I wish languages made it easier (or possible) to track index ownership at compile time.
You can in Rust! You just bundle it with a lifetime.
But... This loses the reason people are using indices to begin with: because the borrow checker cannot track what they do.
Re: Zig: Pointer Stability for ArrayLists
#59Earlier quoted context omitted.
What are some examples of things you "always" need that require unsafe Rust?
[dead]
> for instance by causing a stack overflow
That's not "for instance", that's literally the only place Rust has unfixable UB on embedded (code on OS has other such things, e.g. reading/writing to `/proc/self/mem`).
> projects that need performance often use unsafe
You'll be surprised to hear how often it's not needed at all. And when it is, you'll be surprised to hear how many times you can still avoid it with some tricks. Contrary to popular belief, performance isn't the most common reason for unsafe (FFI probably is).
Re: Zig: Pointer Stability for ArrayLists
#60Constant headache in C++ with `std::vector` element references. Zig's explicit stability here is a welcome relief for data structures.
It seems you misunderstood. It's not an explicit stability guarantee (such things is not possible), it's a debugging helper to crash the program more easily when it happens, requiring you to annotate the code.