dbaupp

63 ms·

541.
by dbaupp 9y ago
The syntax was a bit confusing: T: Sync means (&T): Send and also (&T): Sync. T being Send or not doesn't affect the threadsafety of &T (Send is about transferring ownership which cannot happen with a &T). You are corre
542.
by dbaupp 9y ago
Could you be more specific about what you mean? The relevant (i.e. when it isn't premature optimisation: benchmarks have been run) alternatives here are 1. always risk memory unsafety, fast 2. crash on conditions that would trigger mem
543.
by dbaupp 9y ago
It is the responsibility of cross-thread communication abstractions to use the right fencing (if it is touting itself as safe), probably with the various things in std::sync (especially ...::atomics) if it is pure Rust. For instance, spawni
544.
by dbaupp 9y ago
Data races can lead to other more conventional displays of memory unsafety. For instance, a read of a pointer length pair (a &[T] slice in Rust) while a write is occuring could resulting in a torn read where the pointer is the pre-write
545.
by dbaupp 9y ago
Send and Sync are about data races, which lead to memory unsafety, not other forms of thread safety (like dead lock freedom, or maintaining non-unsafe relationships between fields). If there's no unsafe code, then there's no way t
546.
by dbaupp 9y ago
I have found it very interesting to use the safe function when debug_asserts are on and the unsafe one otherwise (or more generally, some abstraction over safe/unsafe variants that compiles away to nothing in the optimised case). This
547.
by dbaupp 9y ago
C and other FFI is fundamentally outside the control of the Rust compiler (or any other non-C compiler) and, furthermore, the foreign functions can have arbitrarily complicated preconditions (or plain bugs) that lead to memory safety violat
548.
by dbaupp 9y ago
That isn't yet an existing sanitizer. :) It is definitely an important missing piece to bridge the gap to ASan/TSan, but it's still just a proposal/work in progress, not least because, AIUI, the precise rules it needs
549.
by dbaupp 9y ago
As you say, none of the existing sanitisers catch Rust-specific problems, which is, I assume, what the parent meant by "for Rust". That said, they will likely catch many of the consequences of such violations, just not pinpoint th
550.
by dbaupp 9y ago
That is mentioned elsewhere in this very thread, where it is also pointed out that that isn't a general solution (`yes` can print more than just y).
551.
by dbaupp 9y ago
> But doesn't this make the typical use case (just a few "yes"s needed) slower, since first it has to fill a buffer? One could put a write in the memcpy loop, so that first it writes one copy of the string, then two, th
552.
by dbaupp 9y ago
I guess that could indeed be annoying for reading code, especially if the labelled block/loop is very long (I personally usually end up using these for short nested loops, longer loops usually get broken out into separate functions, an
553.
by dbaupp 9y ago
Of course it is strictly less powerful than gotos. That's actually the point of the more structured constructs: they are more restrictive and so can be reasoned about more easily. Note that I'm specifically piking up on labelled b
554.
by dbaupp 9y ago
Your specific example sounds like the kind of thing addressed by more powerful structure: labelled break, as appears in Java, JS, Rust and Swift (among others, I'm sure). Of course, thinking about labelled break is just dreaming when r
555.
by dbaupp 9y ago
I'm curious how the database works with, say, external CI systems like Travis and on multi-developer projects? Is it (or can it be, sensibly) committed to the repository or otherwise persistent with/near the code so that it transf
556.
by dbaupp 9y ago
There's a subtlety here: the "actual" memory unsafety may manifest elsewhere, if the `unsafe` keyword just allows violating constraints that other (possibly-safe) functions rely on. That is, this touches on the whole "bo
557.
by dbaupp 9y ago
> Yes, and additionally there are some algorithms that are safe, but to implement require unsafe blocks. I believe kibwen's point is that every algorithm is safe (when implemented correctly), since any memory safety violations i
558.
by dbaupp 9y ago
Rust has had backward compatibility since 1.0: https://blog.rust-lang.org/2014/10/30/Stability.html
559.
by dbaupp 9y ago
The article covers both of your points: > Rust is supposed to be an excellent systems programming language, having the ability to go extremely close to the bare metal, while offering a thick layer of security and expressiveness which C
560.
by dbaupp 9y ago
It's a little glib, but Python 3 (and Ruby, I believe) both has checked array access and vacuously has overflow checking given integers can't overflow (by default).
561.
by dbaupp 9y ago
You are getting the join from itertools. There's no join on iterators in the standard library, only on &[T] (which is why the collect is needed). A quick search of itertools docs indicates there's no join method in it that t
562.
by dbaupp 9y ago
It would be great if it was, but it's also infeasible for a lot of code (at the moment anyway): it takes too much time and effort, and, in the FFI case, requires proving a whole external library correct too.
563.
by dbaupp 9y ago
Exclusive by default is designed to fit with 0-based indexing (0..length(v), instead 0..(length(v)-1)). That said, this thinking is less relevant in languages with iterators/ranges and doubly so ones that offer a way to explicitly, but
564.
by dbaupp 9y ago
Rust puts a reasonably large amount of effort into making shared memory concurrency safe. Move semantics, borrow checking and the Send/Sync traits combine to eliminate/reduce many of the pitfalls (e.g. data races) which motivated
565.
by dbaupp 9y ago
unique_ptr requires an allocation whereas this does not, but it is using the same language features as unique_ptr.
566.
by dbaupp 9y ago
Go rolled back a lot of their use of the systems programming label, E.g. the first version of the website http://web.archive.org/web/20091111073232/Http://golang.org has it in the heading.
567.
by dbaupp 9y ago
I think you missed the precise qualification of my comment: this only applies when the compiler can't tell what exceptions can occur, like in C++, Rust and even Java, and so needs to be able to handle any/all of them. The most bas
568.
by dbaupp 9y ago
(Explanation of the /s: panics use the same mechanism, so the compiler and libraries unfortunately still have to be just as defensive when they're enabled. When the compiler is in -C panic=abort mode, it doesn't suffer from t
569.
by dbaupp 9y ago
The code there is reading into a buffer; I'm guessing optimisations weren't turned on.
570.
by dbaupp 9y ago
According to the developer survey last year, most of the community is using a stable compiler in some form[0]. I can only imagine that the ratio has improved since then, especially with custom derives in 1.15. Additionally, I semiregularly

More ›