dbaupp

87 ms·

781.
by dbaupp 10y ago
Have you seen the FFI omnibus http://jakegoulding.com/rust-ffi-omnibus/ which includes C# examples?
782.
by dbaupp 10y ago
> Rust as a language is now realizing the benefits of borrow checking. As the article points out, the syntax doesn't have to distinguish between move and assign. The borrow checker will catch a reuse of something already moved awa
783.
by dbaupp 10y ago
Late comment, but aren't stack probes entirely predicated on having working guard pages? I.e. they only exist to guarantee that the guard page is accessed before anything else, when a frame is larger than the page.
784.
by dbaupp 10y ago
> We considered reducing the scope, but ultimately decided to keep the scope pretty broad because writing underhanded code in Rust is hard Are we sure of this? The contest may prove otherwise. Half-jokes aside, it would be surprising i
785.
by dbaupp 10y ago
> But others point out that explicit lifetime annotation is not required to evaluate memory safety [3]. I think you've extrapolated a bit too much from that answer: the code still has to be semantically lifetime-correct, even if t
786.
by dbaupp 10y ago
> Rust: language is still evolving. The language has been at 1.0 and hence backwards-compatibility for a year and a half. Features are being added, but existing code is stable now, with a similar (or maybe even more strict) compatibili
787.
by dbaupp 10y ago
This is a little optimistic: being able to tractibly reason about atomicity in weak memory models like C11 is still at the cutting edge of CS research. It is really hard to prove nontrivial data structures are correct.
788.
by dbaupp 10y ago
Yes, and a []byte is even going to have at least as much inline overhead: it stores 24 bytes (length, capacity, pointer), and of course plus the 4 bytes of actual data. Even on a 32-bit platform, the []byte inline storage is 12 bytes.
789.
by dbaupp 10y ago
Whatever one can do on an i128, one can do "manually" on an array of bytes, e.g. coerce to a pair of u64s to avoid having to manipulate each byte individually.
790.
by dbaupp 10y ago
I don't see the obvious problem (fwiw, I really dislike such rhetorical devices): presumably net.IP could a struct that contains a [16]byte and an isV4 flag.
791.
by dbaupp 10y ago
One of Rust's strongest features is its ability to outlaw data races. In this case, the 128-bit types only provide mutations that take &mut self, that is, a unique unaliased pointer, meaning there's no way to concurrently muta
792.
by dbaupp 10y ago
Rust offers non-allocating fixed-sized arrays, so a GUID could be a (wrapper around) [u8; 16] and an IPv6 address could be [u16; 8].
793.
by dbaupp 10y ago
Assuming you're talking about the python library, it is more going for asynchronous IO and other more "concurrency" things than the data parallelism that rayon is designed for.
794.
by dbaupp 10y ago
Rust can't stop random libraries from providing abstractions like this, but it does allow such libraries to be written to absolutely minimise overhead and maximise performance for when people opt in to using it. If this sort of paralle
795.
by dbaupp 10y ago
I imagine the warning is following the rules for explicit constructors/operators in C++: an if condition is considered an "explicit" call to an `operator bool`. http://en.cppreference.com/w/cpp/langu
796.
by dbaupp 10y ago
Python is capable, via the ctypes module. The problems include: - performance: implementations being interpreted, and relying on dynamic typing mean that Python is almost always slower than compiled languages. - the run-time: Python assumes
797.
by dbaupp 10y ago
> Every time a program (ex: compiler) tries to guess what its user (ex: developer) meant, That's one approach to fixing errors, but there's another: tell the programmer that there's an error, and let them decide the best
798.
by dbaupp 10y ago
A major problem with undefined behaviour and compilers exploiting it is how unforgiving they are: there's no hint to the programmer (unless they explicitly opt in to a sanitiser, which they should, but usually don't) that they hav
799.
by dbaupp 10y ago
I disagree: this sort of operation that seems safe is some of the most deceptive code to write... there's always the risk of reading a little bit more than intended or incrementing a pointer a little too far and hitting undefined behav
800.
by dbaupp 10y ago
Compilers understand memcpy, especially in the context of type punning (historically being the recommended standards-compliant way to do it) where one has small constant sizes. The copy_nonoverlapping "function" is actually a comp
801.
by dbaupp 10y ago
FYI, "apologist" is often not used to literally mean "one who apologises", but rather "one who defends"[1], with a negative connotation (at least in my experience). I would guess the "C apologism" in
802.
by dbaupp 10y ago
Furthermore, it's terminology from mathematics, where, just like the lambda calculus, mutation isn't a thing: https://en.wikipedia.org/wiki/Variable_(mathematics)
803.
by dbaupp 10y ago
That code looks like it could (and should, IMO) be refactored to put the unsafe code in more contained locations, e.g. the &[u8] could be manipulated into a (&[u64], &[u8]) pair (with the main sequence of values, and the trailin
804.
by dbaupp 10y ago
Reading an array out of bounds is definitely unlikely to be correct/be a security vulnerability. Memory safety is absolutely a prerequisite for any other sort of safety one might want.
805.
by dbaupp 10y ago
> But to answer your question, those languages are no safer than C++. I can write a C plugin in both that contains memory leaks and various safety issues. And in fact, both projects have had their own security problems. This definition
806.
by dbaupp 10y ago
Suppressing the unused variable warning is: - unrelated to the dangling pointers - not suppressing a warning about a memory safety problem - not effecting the lack of warnings for the memory safety problems: remove the `(void)y;` line and t
807.
by dbaupp 10y ago
Yes, I'm purposely suppressing the unused variable warning with the (void)y;, because presumably real code will actually do something with the value: I could've printed y or left out that line, whatever, the compilers still don&#x
808.
by dbaupp 10y ago
> C++ compilers tend to give pretty good warnings that you can treat as errors They miss far too many simple cases for this to possibly be a sensible claim, e.g. neither gcc -Wall nor clang -Weverything warn about the two massive probl
809.
by dbaupp 10y ago
Huh, so are you implying that hyper should stay synchronous so that it doesn't appear to just be copying things from 40 years ago?! This comment sounds like you think that it was good back then, but now you don't know what to thin
810.
by dbaupp 10y ago
Risk analysis is typically done including both the probability of a problem and the impact of the problem. Not including the former in an analysis will result in spending vastly disproportionate amounts of effort on exceedingly rare problem

More ›