5 ms·

I'm curious to learn more about your position -- have you written it down in more detail elsewhere? Rust doesn't have this kind of undefined behavior AFAIK? A

I'm curious to learn more about your position -- have you written it down in more detail elsewhere? Rust doesn't have this kind of undefined behavior AFAIK? Are you arguing that C and C++ should have it, but Rust doesn't need to even though it's competing perf-wise with C and C++ in this space?

microcolonel 11y ago
https://doc.rust-lang.org/reference.html#behavior-not-considered-unsafe https://doc.rust-lang.org/reference.html#behavior-not-consid... >• Integer overflow > ◦ Overflow is considered "unexpected" behavior and is always user-error, unless the wrapping primitives are used. In non-optimized builds, the compiler will insert debug checks that panic on overflow, but in optimized builds overflow instead results in wrapped values. See RFC 560 for the rationale and more details. (also important to note that when they say "RFC 560", they are referring to Rust RFCs and not IETF RFCs)
pcwalton 11y ago
> Are you arguing that C and C++ should have it, but Rust doesn't need to even though it's competing perf-wise with C and C++ in this space? Yes. Other languages like Swift generally don't need it either. The big wins from exploiting undefined behavior in C come from mistakes that C's designers made in 1978: signed int being the easiest thing to use for loops over array indices, the any-pointer-can-alias-anything-else style, the uselessness of const for optimization, and null pointers. Rust (and e.g. Swift, for the most part) made none of these choices, and so they can reap the benefits of aggressive compiler optimizations without the undefined behavior. (Digression: I can't blame C's designers for these mistakes, of course: it was 1978! But I think that in 2016 we should just accept that there were things we didn't do right in 1978, because we didn't know as much then as we do now. In most other engineering industries the idea that we made mistakes 35 years ago and that modern designs are better is uncontroversial, but for some reason in computing we have rose-colored glasses for the early days of Unix. Everyone wants to blame the compiler authors because they don't want to admit C has flaws!) These issues don't necessarily apply to other languages. I believe that if you design a language optimally you don't need to fall back on undefined behavior to get good performance. But I don't believe C is that language, and I think attempts to dial back undefined behavior without changing C are missing the point.
- haberman 11y ago
  Wow, if what you say is true, that's even more of a benefit for a language like Rust. Memory safety is awesome, but keeping the same performance while removing undefined behavior is huge. Another question: how do "unsafe Rust" (ie. Rust inside unsafe blocks) and C compare in this sense? If satisfying the borrow checker for some bit of code is too hard, is writing in unsafe Rust better/safer than C?
  - pcwalton 11y ago
    Currently, the aliasing rules for unsafe code are "any pointers can alias"—i.e. no type based alias analysis (TBAA), a.k.a. strict-aliasing. (This is because LLVM has no concept of TBAA at the IR level; it's something the frontend supplies explicitly.) There is an open question as to how much this will affect our ability to perform alias-based optimizations, given that a lot of our primitives are implemented with unsafe code under the hood. I'm optimistic that it can be solved (although some others on the team, like Niko, are less optimistic).

microcolonel 11y ago

https://doc.rust-lang.org/reference.html#behavior-not-considered-unsafe https://doc.rust-lang.org/reference.html#behavior-not-consid... >• Integer overflow > ◦ Overflow is considered "unexpected" behavior and is always user-error, unless the wrapping primitives are used. In non-optimized builds, the compiler will insert debug checks that panic on overflow, but in optimized builds overflow instead results in wrapped values. See RFC 560 for the rationale and more details. (also important to note that when they say "RFC 560", they are referring to Rust RFCs and not IETF RFCs)

pcwalton 11y ago

> Are you arguing that C and C++ should have it, but Rust doesn't need to even though it's competing perf-wise with C and C++ in this space? Yes. Other languages like Swift generally don't need it either. The big wins from exploiting undefined behavior in C come from mistakes that C's designers made in 1978: signed int being the easiest thing to use for loops over array indices, the any-pointer-can-alias-anything-else style, the uselessness of const for optimization, and null pointers. Rust (and e.g. Swift, for the most part) made none of these choices, and so they can reap the benefits of aggressive compiler optimizations without the undefined behavior. (Digression: I can't blame C's designers for these mistakes, of course: it was 1978! But I think that in 2016 we should just accept that there were things we didn't do right in 1978, because we didn't know as much then as we do now. In most other engineering industries the idea that we made mistakes 35 years ago and that modern designs are better is uncontroversial, but for some reason in computing we have rose-colored glasses for the early days of Unix. Everyone wants to blame the compiler authors because they don't want to admit C has flaws!) These issues don't necessarily apply to other languages. I believe that if you design a language optimally you don't need to fall back on undefined behavior to get good performance. But I don't believe C is that language, and I think attempts to dial back undefined behavior without changing C are missing the point.

haberman 11y ago
Wow, if what you say is true, that's even more of a benefit for a language like Rust. Memory safety is awesome, but keeping the same performance while removing undefined behavior is huge. Another question: how do "unsafe Rust" (ie. Rust inside unsafe blocks) and C compare in this sense? If satisfying the borrow checker for some bit of code is too hard, is writing in unsafe Rust better/safer than C?
- pcwalton 11y ago
  Currently, the aliasing rules for unsafe code are "any pointers can alias"—i.e. no type based alias analysis (TBAA), a.k.a. strict-aliasing. (This is because LLVM has no concept of TBAA at the IR level; it's something the frontend supplies explicitly.) There is an open question as to how much this will affect our ability to perform alias-based optimizations, given that a lot of our primitives are implemented with unsafe code under the hood. I'm optimistic that it can be solved (although some others on the team, like Niko, are less optimistic).