451–460 of 492 posts
You mean the implementation is faster than the one in C. Because nothing is “faster than C”.
It's not just "a sufficiently smart compiler", without completely unrealistic (as in "halting problem" unrealistic, in the general case) "smartness".
So no, C is inherently slower than some other languages.
Earlier quoted context omitted.
The usual answer is: You only need to verify the unsafe blocks, not every block. Though 'unsafe' in Rust is actually even less safe than regular C, if a bit more predictable, so there's a crossover point where you really shouldn't have bothered. The Rust compiler is indeed better than the C one, largely because of having more information and doing full-program optimisation. A `vec_foo = vec_foo.into_iter().map(...).c…
I have been told that "unsafe" affects code outside of that block, but hopefully steveklabnik may explain it better (again). > isn't going to do any bounds checks or allocate. You need to add explicit bounds check or explicitly allocate in C though. It is not there if you do not add it yourself.
Yes — in C you can skip the bounds-checks and allocation, because you can convince yourself they aren't needed; the problem is you may be wrong, either immediately or after later refactoring.
In other memory-safe languages you don't risk the buffer overrun, but it's likely you'll get the bounds checks and allocation, and you have the overhead of GC.
Rust is close to alone in doing both.
Earlier quoted context omitted.
As you point out later, a SIGBRT or a SIGBUS would both be perfectly safe and really no different than a panic. With enough infra you could convert them to panic anyway (but probably not worth the effort).
Well, that's the thing though: in terms of Rust and Go and other safe programming languages, CPU exceptions are not "safe" even though they are not inherently dangerous. The point is that the subset of the language that is safe can't generate them, period. They are not accounted for in safe code. There are uses for this, especially since some code will run in environments where you can not simply handle it, but it's…
In Rust, the CPU exception resulting from a stack overflow is considered safe. The compiler uses stack probing to ensure that as long as there is at least one page of unmapped memory below the stack (guard page), the program will reliably fault on it rather than continuing to access memory further below. In most environments it is possible to set up a guard page, including Linux kernel code if CONFIG_VMAP_STACK is enabled. But there are other environments where it’s not, such as WebAssembly and some microcontrollers. In those environments, the backend would have to add explicit checks to function prologs to ensure enough stack is available. I say “would have to”, not “does”: I’ve heard that on at least the microcontrollers, there are no such checks and Rust is just unsound at the moment. Not sure about WebAssembly.
Meanwhile, Go uses CPU exceptions to handle nil dereferences.
Earlier quoted context omitted.
Well, that's the thing though: in terms of Rust and Go and other safe programming languages, CPU exceptions are not "safe" even though they are not inherently dangerous. The point is that the subset of the language that is safe can't generate them, period. They are not accounted for in safe code. There are uses for this, especially since some code will run in environments where you can not simply handle it, but it's…
That’s largely true, but there are some exceptions (pun not intended). In Rust, the CPU exception resulting from a stack overflow is considered safe. The compiler uses stack probing to ensure that as long as there is at least one page of unmapped memory below the stack (guard page), the program will reliably fault on it rather than continuing to access memory further below. In most environments it is possible to set…
That said, I actually entirely forgot Go catches nil derefs in a segfault handler. I guess it's not a big deal since Go isn't really suitable for free-standing environments where avoiding CPU exceptions is sometimes more useful, so there's no particular reason why the runtime can't rely on it.
Earlier quoted context omitted.
> It's really only encapsulated in the sense that if you have a finite and small set of unsafe blocks, you can audit them easier and be pretty sure that your memory safety bugs are in there. This reality really doesn't exist much anymore because of how much unsafe is often ued, and since you you have to audit all of them, whether they come from a library or not, it's not as useful to claim encapsulation as one thinks…
> and we've added support for Miri to make its runs many times faster Whoa. This might be the kick in the ass I needed to give cargo-nextest a whirl in my projects. Miri being slow is the single biggest annoyance I have with it!
[1] https://bsky.app/profile/lukaswirth.bsky.social/post/3lkg2sl...
Earlier quoted context omitted.
It literally returns a valid output value as an error.
An error value is valid output in both cases.
average(INT_MAX,INTMAX) should return INT_MAX, but it will get that wrong and return -1.
average(0,-2) should not return a special error-code value, but this code will do just that, making -1 an ambiguous output value.
Even its comment is wrong. We can see from the signature of the function that there can be no value that indicates an error, as every possible value of int may be a legitimate output value.
It's possible to implement this function in a portable and standard way though, along the lines of [0].
[0] https://stackoverflow.com/a/61711253/ (Disclosure: this is my code.)
Earlier quoted context omitted.
You can swear on anything, does not make it any more true. ¯\_(ツ)_/¯ All you do is defend very anecdotal evidence. Surely you can see this is not logically compelling.
In case you're ESL, you're downvoted because in this context "I swear" means "here comes some anecdotal evidence" and not "I promise this is true."
Thanks for the clarification. Appreciate it. <3
Earlier quoted context omitted.
You can swear on anything, does not make it any more true. ¯\_(ツ)_/¯ All you do is defend very anecdotal evidence. Surely you can see this is not logically compelling.
He is replying to YOUR anecdotal experience though.
Appreciate the perspective however. It's helpful.