2 ms·

Sure. At which point, again, there is still a solution, just that Vec itself won't help here. However, it's worth noting that at this level of "everything is u

Sure. At which point, again, there is still a solution, just that Vec itself won't help here. However, it's worth noting that at this level of "everything is unsafe" the problem is intractable. Just as you trust Rust's stdlib to have safely-crafted syscalls, you trust Rust's compiler to generate the right code if you tell it to do a volatile clear on a drop/resize. You have to define your trust level somewhere. For some, it is "I have audited my small amount of unsafe code (if any), and I trust Rust's stdlib". The parent's comment was addressing that level of trust. If you're not trusting the stdlib, you also probably don't trust the compiler to generate the right code; at which point the most you can do is try to keep things safe, you can never succeed short of auditing the generated asm extensively.

mehrdadn 9y ago
> You have to define your trust level somewhere. If you're not trusting the stdlib, you also probably don't trust the compiler to generate the right code. Aw, come on. Why are you resorting to these inane arguments? Yes, people trust their compilers to be bug-free. No, that does not -- in any way, shape or form -- logically imply that they should also trust every single version of every kernel and ALSO every single kernel-module from every possible vendor and ALSO every single user-level library that their program might run on top of, whether from the past or the future, to be bug-free. To just throw your hands up and claim the threat levels are somehow comparable to each other is just disingenuous.
- Manishearth 9y ago
  > To just throw your hands up and claim the threat levels are somehow comparable to each other is just disingenuous I'm not, I'm saying they are for some. Different folks have different trust models. I'm saying that it's a logical threat/trust model where you both trust the compiler and the kernel. This isn't everyone's model. This is clearly not yours. But this wasn't clear in the original comment and cwzwarich addressed this model (as well as yours!) and that's what I was saying. Defense in depth is good, but, again, that wasn't what was being _asked for_. You forcibly took a discussion in a different direction from what was originally being discussed, reframing everything to a strictly absolutist view of trust, and are somehow bewildered that folks aren't understanding what you're saying. I don't really see the point in this discussion -- it's a metadiscussion about whether or not including an "assuming safety" portion in a comment was appropriate, and doesn't add anything.
  - mehrdadn 9y ago
    > You forcibly took a discussion in a different direction from what was originally being discussed, reframing everything to a strictly absolutist view of trust, and are somehow bewildered that folks aren't understanding what you're saying. Huh? My trust model was the same as that of those who want memory to be zero'd, like the one earlier [1]. People ask for that because so many attacks we see today are in external libraries and kernel-mode, and hence people are worried about that. That is not something in my fantasy; that's the model of the world we live in. You guys decided to deliberately ignore that and pretend a safe language implies worrying about attacks in external code is ridiculous. I was trying to steer back the discussion to that model. Apparently I failed; you guys win. Rust programs are invincible by definition. [1] https://news.ycombinator.com/item?id=15967604 https://news.ycombinator.com/item?id=15967604
    - Manishearth 9y ago
      > Apparently I failed; you guys win. Rust programs are invincible by definition. This is not what I'm saying, and you're being deliberately obtuse at this point. > My trust model was the same as that of those who want memory to be zero'd, like the one earlier [1]. This person was asking about network exploits where this has been a problem. Rust helps prevent those exploits. Does it fix the problem completely? Of course not. Does it fix the problem to the point where it's "not worth worrying about"? Depends, depends on where you stop worrying about things, and this is why the original commented addressed both cases. Revisit the first comment and consider if others perhaps interpreted it more broadly than you. I am done discussing this. You're putting words into my mouth, and being deliberately obtuse.

mehrdadn 9y ago

> You have to define your trust level somewhere. If you're not trusting the stdlib, you also probably don't trust the compiler to generate the right code. Aw, come on. Why are you resorting to these inane arguments? Yes, people trust their compilers to be bug-free. No, that does not -- in any way, shape or form -- logically imply that they should also trust every single version of every kernel and ALSO every single kernel-module from every possible vendor and ALSO every single user-level library that their program might run on top of, whether from the past or the future, to be bug-free. To just throw your hands up and claim the threat levels are somehow comparable to each other is just disingenuous.

Manishearth 9y ago
> To just throw your hands up and claim the threat levels are somehow comparable to each other is just disingenuous I'm not, I'm saying they are for some. Different folks have different trust models. I'm saying that it's a logical threat/trust model where you both trust the compiler and the kernel. This isn't everyone's model. This is clearly not yours. But this wasn't clear in the original comment and cwzwarich addressed this model (as well as yours!) and that's what I was saying. Defense in depth is good, but, again, that wasn't what was being _asked for_. You forcibly took a discussion in a different direction from what was originally being discussed, reframing everything to a strictly absolutist view of trust, and are somehow bewildered that folks aren't understanding what you're saying. I don't really see the point in this discussion -- it's a metadiscussion about whether or not including an "assuming safety" portion in a comment was appropriate, and doesn't add anything.
- mehrdadn 9y ago
  > You forcibly took a discussion in a different direction from what was originally being discussed, reframing everything to a strictly absolutist view of trust, and are somehow bewildered that folks aren't understanding what you're saying. Huh? My trust model was the same as that of those who want memory to be zero'd, like the one earlier [1]. People ask for that because so many attacks we see today are in external libraries and kernel-mode, and hence people are worried about that. That is not something in my fantasy; that's the model of the world we live in. You guys decided to deliberately ignore that and pretend a safe language implies worrying about attacks in external code is ridiculous. I was trying to steer back the discussion to that model. Apparently I failed; you guys win. Rust programs are invincible by definition. [1] https://news.ycombinator.com/item?id=15967604 https://news.ycombinator.com/item?id=15967604
  - Manishearth 9y ago
    > Apparently I failed; you guys win. Rust programs are invincible by definition. This is not what I'm saying, and you're being deliberately obtuse at this point. > My trust model was the same as that of those who want memory to be zero'd, like the one earlier [1]. This person was asking about network exploits where this has been a problem. Rust helps prevent those exploits. Does it fix the problem completely? Of course not. Does it fix the problem to the point where it's "not worth worrying about"? Depends, depends on where you stop worrying about things, and this is why the original commented addressed both cases. Revisit the first comment and consider if others perhaps interpreted it more broadly than you. I am done discussing this. You're putting words into my mouth, and being deliberately obtuse.