4 ms·

I don't think this is very surprising; if you do something unsafe hapharzardly within an unsafe block you can put the program in a state a safe program would no

I don't think this is very surprising; if you do something unsafe hapharzardly within an unsafe block you can put the program in a state a safe program would not be able to reach, so further computation is in an unsafe state. In fact isn't this why we have unsafe in the first place; so that such code can be more easily verified? I disagree with the notion the author suggests that the problem isn't in the unsafe code.

Manishearth 11y ago
The thing is that it's not always possible to scope unsafety to unsafe blocks. The example of vec in the post above isn't about haphazard unsafe code, it's about code within Vec's module boundary being able to mess up invariants without needing to use unsafe. This could be fixed with things like "unsafe fields" and "unsafe types", but IMO that's not really necessary.
ralfj 11y ago
To reach a conclusion here, we will have to agree on what it means to be the "cause of the problem". It is true that if a program crashes, then there has to be some unsafe code in that program. This statement is however not very helpful, because pretty much all programs use libstd which contains unsafe code. So, I'd define the "cause" of a bug to be the piece of code that you fix to get rid of the bug. If `evil` was in libstd, the fix would be to remove `evil` (or somehow make it take a default value, grow the `Vec` to be large enough and fill the two new slots with that default value). In that sense, the problem here clearly was in the safe code `evil`, since it's that code which had to be changed to get rid of the problem.
- Gankro 11y ago
  The guarantee I prefer is "If there's a segfault and you didn't write `unsafe`, it's not your fault". This is not necessarily referring to a single change, but rather the application as a whole. Dependencies like libstd are ignored here . As soon as there's any `unsafe` in your code, you've unlocked hard mode and everything is probably your fault.

Manishearth 11y ago

The thing is that it's not always possible to scope unsafety to unsafe blocks. The example of vec in the post above isn't about haphazard unsafe code, it's about code within Vec's module boundary being able to mess up invariants without needing to use unsafe. This could be fixed with things like "unsafe fields" and "unsafe types", but IMO that's not really necessary.

ralfj 11y ago

To reach a conclusion here, we will have to agree on what it means to be the "cause of the problem". It is true that if a program crashes, then there has to be some unsafe code in that program. This statement is however not very helpful, because pretty much all programs use libstd which contains unsafe code. So, I'd define the "cause" of a bug to be the piece of code that you fix to get rid of the bug. If `evil` was in libstd, the fix would be to remove `evil` (or somehow make it take a default value, grow the `Vec` to be large enough and fill the two new slots with that default value). In that sense, the problem here clearly was in the safe code `evil`, since it's that code which had to be changed to get rid of the problem.

Gankro 11y ago
The guarantee I prefer is "If there's a segfault and you didn't write `unsafe`, it's not your fault". This is not necessarily referring to a single change, but rather the application as a whole. Dependencies like libstd are ignored here . As soon as there's any `unsafe` in your code, you've unlocked hard mode and everything is probably your fault.