7 ms·

Look at my username. I didn't like it since rust called themself memory safe and didn't force us to do an array bounds check. It's been 10years and they still h

Look at my username. I didn't like it since rust called themself memory safe and didn't force us to do an array bounds check. It's been 10years and they still haven't done it (Also all the hype and fearlessness is obnoxious)

throwaway17_17 4y ago
I was under the impression that unless inside an unsafe block, Rust required/automatically-placed bounds checks on array accesses. The out there was for situations where the compiler could 'prove' that the index was within bounds statically. But maybe I was wrong about that. With such a strong focus on bounds checking, are there any 'systems programming' languages that you do find acceptable?
- ArrayBoundCheck 4y ago
  > automatically-placed bounds checks on array accesses That's exactly why I get annoyed. How will it be fast if it branches on every access > where the compiler could 'prove' The compiler doesn't prove shit. It lets the optimizer do it. It's extremely easy to fool the optimizer > there any 'systems programming' languages The ones that don't make false claims (so not v or rust) and don't insert code I don't want
  - throwaway17_17 4y ago
    Your objection to saying my saying "the compiler could 'prove'" is one of the reasons I put the quotes around prove. Also, thanks for answering, I didn't want my question to seem like baiting or trying to start a string of downvotes, etc. I am honestly interested developer stances on languages, for whatever reason those stances exist.
- gpm 4y ago
  Even in unsafe blocks, rust automatically places bounds checks on array accesses. It's just that in unsafe blocks you get access to additional more verbose functions, such as "array.get_unchecked(idx)" instead of "array[i]", that don't perform bounds checks. Unsafe blocks don't change the semantics of code, they just let you write code you couldn't write outside of them.
  - throwaway17_17 4y ago
    That's interesting, I don't know that I would have thought about the behavior of the subscript operator as a semantic issue in that way. I guess it is a different view point to mine. I, nearly, universally view the subscript operator as a function that takes a Nat and produces the element of the array/list/etc that is stored at that index. So, for me, the placing of bounds checks when using that function is an implementation detail and therefore, if unsafe removes it, it does not effect the semantics.
    - TheDong 4y ago
      You're right that '[i]' is just a function call ('.index(i)' https://doc.rust-lang.org/std/ops/trait.Index.html https://doc.rust-lang.org/std/ops/trait.Index.html). > So, for me, the placing of bounds checks when using that function is an implementation detail and therefore, if unsafe removes it, it does not effect the semantics. The function is not marked as unsafe, so it promises that it will not corrupt memory and thus must perform bound checks. The designation of safe/unsafe for a function is compile-time and promises certain semantics. It would be a semantic issue for a safe function to invoke unsafe behavior. Even within an 'unsafe' block, calling safe functions should not cause memory corruption as long as your other unsafe calls / unsafe code didn't do anything "wrong". Anyway, to implement a function like that, you'd need: fn index(i) -> T { if is_caller_in_unsafe_block() { return unsafe { unsafe_index(i) } } ... } The compiler does not, as far as I'm aware, have any "is_caller_in_unsafe_block" primitive, and adding one seems quite fraught.
      - ArrayBoundCheck 4y ago
Ygg2 4y ago
That's just FUD. Rust inserts bounds check automatically in debug mode, if needed. Second, using iterators makes bounds checking redundant. And random access `array[intval]` will always be performance crippled if intval is provided by external system at runtime. Even if intval is guaranteed to be between 0..<array.length, you need to converted it to that type.
- ArrayBoundCheck 4y ago
  Just FUD while spreading FUD? Are you trying to say release mode doesn't have runtime checks inserted? What I want is a check outside of the loop then every access inside a loop unchecked and fast. Which isn't what rust does. Then it throws your memory away if you did an oops and went out of bounds
  - pitaj 4y ago
    > What I want is a check outside of the loop then every access inside a loop unchecked and fast. Which isn't what rust does. That's exactly what iterators allow.
    - throwaway17_17 4y ago
      I think the caveat to this is that iterators are a fundamentally different programming 'construct' than a statement block using an index to access elements of a container and then having that index increase with each loop. I tend to treat iterators as a non-factor when discussing semantics of a language as I will always default to them not being a 'language-level' construct. I am not a fan of iterators in any case, but then again, I don't particularly like any higher level constructs in my 'run-time' code.
      - Arnavion 4y ago
        I'm sure you can understand why "I'm going to ignore this part of the language because it damages my argument" might be convincing to yourself but not to others.

throwaway17_17 4y ago

I was under the impression that unless inside an unsafe block, Rust required/automatically-placed bounds checks on array accesses. The out there was for situations where the compiler could 'prove' that the index was within bounds statically. But maybe I was wrong about that. With such a strong focus on bounds checking, are there any 'systems programming' languages that you do find acceptable?

ArrayBoundCheck 4y ago
> automatically-placed bounds checks on array accesses That's exactly why I get annoyed. How will it be fast if it branches on every access > where the compiler could 'prove' The compiler doesn't prove shit. It lets the optimizer do it. It's extremely easy to fool the optimizer > there any 'systems programming' languages The ones that don't make false claims (so not v or rust) and don't insert code I don't want
- throwaway17_17 4y ago
  Your objection to saying my saying "the compiler could 'prove'" is one of the reasons I put the quotes around prove. Also, thanks for answering, I didn't want my question to seem like baiting or trying to start a string of downvotes, etc. I am honestly interested developer stances on languages, for whatever reason those stances exist.
gpm 4y ago
Even in unsafe blocks, rust automatically places bounds checks on array accesses. It's just that in unsafe blocks you get access to additional more verbose functions, such as "array.get_unchecked(idx)" instead of "array[i]", that don't perform bounds checks. Unsafe blocks don't change the semantics of code, they just let you write code you couldn't write outside of them.
- throwaway17_17 4y ago
  That's interesting, I don't know that I would have thought about the behavior of the subscript operator as a semantic issue in that way. I guess it is a different view point to mine. I, nearly, universally view the subscript operator as a function that takes a Nat and produces the element of the array/list/etc that is stored at that index. So, for me, the placing of bounds checks when using that function is an implementation detail and therefore, if unsafe removes it, it does not effect the semantics.
  - TheDong 4y ago
    You're right that '[i]' is just a function call ('.index(i)' https://doc.rust-lang.org/std/ops/trait.Index.html https://doc.rust-lang.org/std/ops/trait.Index.html). > So, for me, the placing of bounds checks when using that function is an implementation detail and therefore, if unsafe removes it, it does not effect the semantics. The function is not marked as unsafe, so it promises that it will not corrupt memory and thus must perform bound checks. The designation of safe/unsafe for a function is compile-time and promises certain semantics. It would be a semantic issue for a safe function to invoke unsafe behavior. Even within an 'unsafe' block, calling safe functions should not cause memory corruption as long as your other unsafe calls / unsafe code didn't do anything "wrong". Anyway, to implement a function like that, you'd need: fn index(i) -> T { if is_caller_in_unsafe_block() { return unsafe { unsafe_index(i) } } ... } The compiler does not, as far as I'm aware, have any "is_caller_in_unsafe_block" primitive, and adding one seems quite fraught.
    - ArrayBoundCheck 4y ago

Ygg2 4y ago

That's just FUD. Rust inserts bounds check automatically in debug mode, if needed. Second, using iterators makes bounds checking redundant. And random access `array[intval]` will always be performance crippled if intval is provided by external system at runtime. Even if intval is guaranteed to be between 0..<array.length, you need to converted it to that type.

ArrayBoundCheck 4y ago
Just FUD while spreading FUD? Are you trying to say release mode doesn't have runtime checks inserted? What I want is a check outside of the loop then every access inside a loop unchecked and fast. Which isn't what rust does. Then it throws your memory away if you did an oops and went out of bounds
- pitaj 4y ago
  > What I want is a check outside of the loop then every access inside a loop unchecked and fast. Which isn't what rust does. That's exactly what iterators allow.
  - throwaway17_17 4y ago
    I think the caveat to this is that iterators are a fundamentally different programming 'construct' than a statement block using an index to access elements of a container and then having that index increase with each loop. I tend to treat iterators as a non-factor when discussing semantics of a language as I will always default to them not being a 'language-level' construct. I am not a fan of iterators in any case, but then again, I don't particularly like any higher level constructs in my 'run-time' code.
    - Arnavion 4y ago
      I'm sure you can understand why "I'm going to ignore this part of the language because it damages my argument" might be convincing to yourself but not to others.