5 ms·

Considering pointer arithmetic is unsafe, there are no other interpretations, I think? I can’t think of an example where this would mask a mistake in Rust. As

Considering pointer arithmetic is unsafe, there are no other interpretations, I think? I can’t think of an example where this would mask a mistake in Rust. As for confusion, both are accepted. I imagine clippy will eventually have advice on this situation. For example, clippy also warns you about taking a reference that the compiler immediatly dereferences. I’m not sure what the long term plans are for clippy, but personally hope it’ll eventually be warnings in the official compiler.

DSMan195276 9y ago
> Considering pointer arithmetic is unsafe I just wanted to point out that this is largely a misconception. Rust, or the Rust creators, do not consider pointer arithmetic to be fundamentally `unsafe`, and the only reason `.offset()` is `unsafe` to begin with is due to optimization concerns[0]. `.wrapping_offset()` exists and is marked safe, despite achieving the exactly same thing as `.offset()` for the majority of scenarios[1], and more-over you can cast any pointer to an integer using only safe code, at which point you can perform all of your arithmetic on the integer and then cast it back also using only safe code[2]. The bottom line is that things like pointer arithmetic are generally not considered unsafe because the operation has defined semantics for what happens. It is only the point where you attempt to use the value, the dereference, that is `unsafe`, as that may blow-up if the value is an invalid memory location. [0] https://github.com/rust-lang/rust/issues/33813 https://github.com/rust-lang/rust/issues/33813 [1] https://play.rust-lang.org/?gist=c9c11545fac3a45550e6810cb579e4e9&version=stable https://play.rust-lang.org/?gist=c9c11545fac3a45550e6810cb57... An example that uses `.wrapping_offset` without `unsafe` to produce a segfault. [2] https://doc.rust-lang.org/book/first-edition/casting-between-types.html#pointer-casts https://doc.rust-lang.org/book/first-edition/casting-between...
- nicoburns 9y ago
  But generally there's no point in doing pointer arithmetic unless you are going to deference the pointer at some point, right?
  - DSMan195276 9y ago
    I mean, that's largely up to you. For Rust, generally probably not, but I would wager there are situations where it might be useful to add some offsets and compare various pointer values without actually ever dereferencing them. My point was more that there is a difference between what people consider to be "bug-likely" operations, and what Rust considers an `unsafe` operation, and because of this I think people are too quick to think the `unsafe` system will always save them and make it easy to verify their code. If you do tons of pointer arithmetic and then do one dereference at the end, you're going to only have one line of `unsafe` code, which is "good". But if that one line blows up, then the actual bug is somewhere in your safe code, not the one line of `unsafe` code, so judging safety based only on how much `unsafe` code is really not a great way to do things. And I don't say this as a theory about what people are thinking. This paper[0] got passed around a bit a while back (Most only Reddit, I can't seem to find a HN page that got very popular), and they quite literally create an `Address` object that exposes a safe `plus` function (for pointer arithmetic) and an `unsafe` `load` function for dereferencing. And then they just do a pretty much straight conversion of the C code, replacing all the pointers with `Address` objects, replacing all of the pointer arithmetic with `plus`s, and replacing all of the dereferences with `load`s. And then they claim it is tons safer then the C code because it uses so little `unsafe` code, despite the fact that it can easily have the exact same bugs the C code can have if there are any bugs in their pointer arithmetic. So, in this situation, the amount of `unsafe` code really doesn't actually matter because it doesn't really mean anything about the number of bugs in the program. All it indicates is that "these are the spots where the program could blow-up", which you could probably already figure out fairly easy from looking at C code. And don't get the wrong idea, I do still like Rust and I think it has some great features in it (And some misfeatures, but that's true of every language). But, at the very least, I think the `unsafe` system leaves a lot to be desired and things like the tutorials give the wrong impression about what `unsafe` actually indicates. [0] https://pdfs.semanticscholar.org/4dc9/61a6922eae5346c593eb183f9c4ed0636f5a.pdf https://pdfs.semanticscholar.org/4dc9/61a6922eae5346c593eb18...
    - Rusky 9y ago
      The idea behind unsafe is that you're not allowed to do that sort of thing. There's obviously not a way to enforce that in the compiler, but that's because unsafe is inherently a way to extend what the compiler can enforce. It's like you're adding code to the compiler. Assuming that's done correctly (as e.g. the stdlib is in the process of being proven to do) then any client safe code is truly known not to have any memory safety problems.

DSMan195276 9y ago

> Considering pointer arithmetic is unsafe I just wanted to point out that this is largely a misconception. Rust, or the Rust creators, do not consider pointer arithmetic to be fundamentally `unsafe`, and the only reason `.offset()` is `unsafe` to begin with is due to optimization concerns[0]. `.wrapping_offset()` exists and is marked safe, despite achieving the exactly same thing as `.offset()` for the majority of scenarios[1], and more-over you can cast any pointer to an integer using only safe code, at which point you can perform all of your arithmetic on the integer and then cast it back also using only safe code[2]. The bottom line is that things like pointer arithmetic are generally not considered unsafe because the operation has defined semantics for what happens. It is only the point where you attempt to use the value, the dereference, that is `unsafe`, as that may blow-up if the value is an invalid memory location. [0] https://github.com/rust-lang/rust/issues/33813 https://github.com/rust-lang/rust/issues/33813 [1] https://play.rust-lang.org/?gist=c9c11545fac3a45550e6810cb579e4e9&version=stable https://play.rust-lang.org/?gist=c9c11545fac3a45550e6810cb57... An example that uses `.wrapping_offset` without `unsafe` to produce a segfault. [2] https://doc.rust-lang.org/book/first-edition/casting-between-types.html#pointer-casts https://doc.rust-lang.org/book/first-edition/casting-between...

nicoburns 9y ago
But generally there's no point in doing pointer arithmetic unless you are going to deference the pointer at some point, right?
- DSMan195276 9y ago
  I mean, that's largely up to you. For Rust, generally probably not, but I would wager there are situations where it might be useful to add some offsets and compare various pointer values without actually ever dereferencing them. My point was more that there is a difference between what people consider to be "bug-likely" operations, and what Rust considers an `unsafe` operation, and because of this I think people are too quick to think the `unsafe` system will always save them and make it easy to verify their code. If you do tons of pointer arithmetic and then do one dereference at the end, you're going to only have one line of `unsafe` code, which is "good". But if that one line blows up, then the actual bug is somewhere in your safe code, not the one line of `unsafe` code, so judging safety based only on how much `unsafe` code is really not a great way to do things. And I don't say this as a theory about what people are thinking. This paper[0] got passed around a bit a while back (Most only Reddit, I can't seem to find a HN page that got very popular), and they quite literally create an `Address` object that exposes a safe `plus` function (for pointer arithmetic) and an `unsafe` `load` function for dereferencing. And then they just do a pretty much straight conversion of the C code, replacing all the pointers with `Address` objects, replacing all of the pointer arithmetic with `plus`s, and replacing all of the dereferences with `load`s. And then they claim it is tons safer then the C code because it uses so little `unsafe` code, despite the fact that it can easily have the exact same bugs the C code can have if there are any bugs in their pointer arithmetic. So, in this situation, the amount of `unsafe` code really doesn't actually matter because it doesn't really mean anything about the number of bugs in the program. All it indicates is that "these are the spots where the program could blow-up", which you could probably already figure out fairly easy from looking at C code. And don't get the wrong idea, I do still like Rust and I think it has some great features in it (And some misfeatures, but that's true of every language). But, at the very least, I think the `unsafe` system leaves a lot to be desired and things like the tutorials give the wrong impression about what `unsafe` actually indicates. [0] https://pdfs.semanticscholar.org/4dc9/61a6922eae5346c593eb183f9c4ed0636f5a.pdf https://pdfs.semanticscholar.org/4dc9/61a6922eae5346c593eb18...
  - Rusky 9y ago
    The idea behind unsafe is that you're not allowed to do that sort of thing. There's obviously not a way to enforce that in the compiler, but that's because unsafe is inherently a way to extend what the compiler can enforce. It's like you're adding code to the compiler. Assuming that's done correctly (as e.g. the stdlib is in the process of being proven to do) then any client safe code is truly known not to have any memory safety problems.