6 ms·

Requisite Rust fanboy'ing: GitHub stats say 90% Rust code.

steveklabnik 10y ago
The author posted on /r/rust with some details: https://www.reddit.com/r/rust/comments/4ihtfa/panopticon_a_libre_crossplatform_disassembler/d2yj305 https://www.reddit.com/r/rust/comments/4ihtfa/panopticon_a_l... A particularly interesting comment: > Also I found iterator invalidation bugs simply by translating > C++ to Rust, thanks Borrow Checker!
- pcwalton 10y ago
  Yeah, it's really interesting how many iterator invalidation bugs you find in real C++ codebases. It's so easy to think that they don't exist until you have a tool (or a human) actively searching for them…
  - dman 10y ago
    Isnt this whole category of bugs easily avoided by using 1. _SECURE_SCL on windows 2. _GLIBCXX_DEBUG on glibc based toolchains
    - Someone 10y ago
      Those do not remove any bugs; it just changes how they are handled (ignore and hope for the best vs print diagnostic and terminate program, and the latter not in all cases)
      - dman 10y ago
        Assuming that tests exist, and have good coverage, wont the checked iterator implementations mentioned above catch most issues with invalid iterators?
        dikaiosune 10y ago
        A big part of what makes Rust great is that it catches those issues at compile-time, no test coverage required, no extra run-time checks required (not that it moots tests, of course). In my experience so far this is a very powerful ally to have when writing software, as it's very useful to surface those issues as early as possible. EDIT: Also: > Assuming that tests exist, and have good coverage That's a very big assumption. Granted my current job is often to clean up codebases that are the opposite of that, so maybe I've got a bias here.
        pcwalton 10y ago
        I don't know of any large, widely used, security critical, heavily scrutinized C++ program that uses those flags in production. I also don't know of any such C++ program that hasn't had game-over use after free bugs. So the answer to your question is somewhere ranging from "we don't know, but unlikely" to "no".
        Someone 10y ago
        For some definition of ‘good coverage’ and ‘most’: yes. I do not think 100% coverage on the code you write alone is enough to get to ‘all', though. For example, if your test declares a vector and calls a function that does v.erase( i, v.end()); with i == v.end(), you get 100% coverage, but in production, that part of the code might be called with i == v.begin(), and that invalidates all iterators on the vector.
    - pcwalton 10y ago
      No. You can dereference those "safe" iterators into dangling references.
deleted 10y ago
[deleted]

The author posted on /r/rust with some details: https://www.reddit.com/r/rust/comments/4ihtfa/panopticon_a_libre_crossplatform_disassembler/d2yj305 https://www.reddit.com/r/rust/comments/4ihtfa/panopticon_a_l... A particularly interesting comment: > Also I found iterator invalidation bugs simply by translating > C++ to Rust, thanks Borrow Checker!

pcwalton 10y ago
Yeah, it's really interesting how many iterator invalidation bugs you find in real C++ codebases. It's so easy to think that they don't exist until you have a tool (or a human) actively searching for them…
- dman 10y ago
  Isnt this whole category of bugs easily avoided by using 1. _SECURE_SCL on windows 2. _GLIBCXX_DEBUG on glibc based toolchains
  - Someone 10y ago
    Those do not remove any bugs; it just changes how they are handled (ignore and hope for the best vs print diagnostic and terminate program, and the latter not in all cases)
    - dman 10y ago
      Assuming that tests exist, and have good coverage, wont the checked iterator implementations mentioned above catch most issues with invalid iterators?
      - dikaiosune 10y ago
        A big part of what makes Rust great is that it catches those issues at compile-time, no test coverage required, no extra run-time checks required (not that it moots tests, of course). In my experience so far this is a very powerful ally to have when writing software, as it's very useful to surface those issues as early as possible. EDIT: Also: > Assuming that tests exist, and have good coverage That's a very big assumption. Granted my current job is often to clean up codebases that are the opposite of that, so maybe I've got a bias here.
      - pcwalton 10y ago
        I don't know of any large, widely used, security critical, heavily scrutinized C++ program that uses those flags in production. I also don't know of any such C++ program that hasn't had game-over use after free bugs. So the answer to your question is somewhere ranging from "we don't know, but unlikely" to "no".
      - Someone 10y ago
        For some definition of ‘good coverage’ and ‘most’: yes. I do not think 100% coverage on the code you write alone is enough to get to ‘all', though. For example, if your test declares a vector and calls a function that does v.erase( i, v.end()); with i == v.end(), you get 100% coverage, but in production, that part of the code might be called with i == v.begin(), and that invalidates all iterators on the vector.
  - pcwalton 10y ago
    No. You can dereference those "safe" iterators into dangling references.

deleted 10y ago

[deleted]