Hacker News Reader

Comment by 0x0 | Hacker News Reader

I don't know rust, but what happens if you get a 0xff as the last byte here, wouldn't i+1 go out of array bounds?

   while i < vec.len() {
            encoded_data.push(vec[i]);
            if vec[i] == 0xff && vec[i + 1] == 0x00 {
                // Skip the 0x00 part here.

View on HN

IIRC, Rust will panic and halt your program. This is one of a handful of errors that Rust can't catch at compile time, and so it inserts run-time checks.

The syntax "vec[i+1]" means "I expect this index to be in bounds, and if it's not, my program is so hopelessly broken it should be shut down immediately."

If you're really confident in your code and you need to wring out the last bit of performance, you could also use:

    unsafe { vec.get_unchecked(i+1) }

...but in this case, your code would produce undefined behavior. If you want to detect this case and recover from it, you could also write:

    if let Some(value) = vec.get(i+1) {
      // Use value.
    } else {
      // Fail with an error.
    }

...or you could immediately exit the current routine with an error if no value is available:

    let value = try!(vec.get(i+1).ok_or(make_an_error()));

If you're writing a lot of parser code, your best bet might be to define a custom macro named that looks something like "try_get!(vec, i+1)" wrapping the final example above.

  > and you need to wring out the last bit of performance,

... and if you've already demonstrated that LLVM hasn't removed the bounds checks itself already.

Since Rust people are reading this.

I find myself wanting to walk an iterator pairwise regularly for stuff like this and I'm using:

    for (cur, next) in (& vec).iter().zip(vec.iter().skip(1)) {
        encoded_data.push(cur);
        if cur == 0xff && next == 0x00 {
            // ...
        }
    }

Is there a better way to write this? What I'd really like is the equivalent to Clojure's partition[1]. I know that the stdlib has windows `(partition n (dec n) seq)` and chunks `(partition n n seq)` implemented on slices but I usually want this on iterators for the lookahead-like behavior shown here.

[1] https://clojuredocs.org/clojure.core/partition

I'm not 100% sure, but https://crates.io/crates/itertools might have what you're looking for.

I think http://bluss.github.io/rust-itertools/doc/itertools/struct.Z... would fit their use case?

The `.windows(usize)` function almost does this, but it uses a runtime width and so has to yield slices rather than tuples.

If you can afford the allocation at every iteration, the iterslide crate might work for you.

https://github.com/slapresta/rust-iterslide

Ooops :( One of many minor bugs, I suppose.

Reply on news.ycombinator.com