thread 'main' panicked at 'attempt to subtract with overflow'

[86me]

First off, just want to say how much I like the concept of this utility. That being said, I am able to encode strings, but unable to decode strings. At first, I thought it might be because I was using OSX, but I'm receiving the same error on an Arch box. Here is an example:

╰ % echo "test"|./base100                                                                12:52 PM 101 ↵
👫👜👪👫🐁

╰ % echo "👫👜👪👫🐁"|RUST_BACKTRACE=1 ./base100 -d                                            1:05 PM 101 ↵
thread 'main' panicked at 'attempt to subtract with overflow', src/main.rs:69:44
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::panicking::default_hook::{{closure}}
   2: std::panicking::default_hook
   3: std::panicking::rust_panic_with_hook
   4: std::panicking::begin_panic_new
   5: std::panicking::begin_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::panicking::panic
   9: base100::main::{{closure}}
  10: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &'a mut F>::call_once
  11: <core::option::Option<T>>::map
  12: <core::iter::Map<I, F> as core::iter::iterator::Iterator>::next
  13: <alloc::vec::Vec<T>>::extend_desugared
  14: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::spec_extend
  15: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
  16: <alloc::vec::Vec<T> as core::iter::traits::FromIterator<T>>::from_iter
  17: core::iter::iterator::Iterator::collect
  18: base100::main
  19: __rust_maybe_catch_panic
  20: std::rt::lang_start
  21: main

[Thiez]

Echo inserts a linefeed, which would be character code '10', which is smaller than 127991, so the decoding crashes. Does it work with echo -n "👫👜👪👫🐁"|RUST_BACKTRACE=1 ./base100 -d ?

[AdamNiederer]

I can't reproduce with echo or echo -n, but I am working an an avx-tastic decoder rewrite which might fix this. Stay tuned!

[86me]

@Thiez Nope. Same error. I've tried both the -n (no newline) switch, as well as $ echo "test\c" with and without -n.

╰ % echo -n "test\c"|base100|RUST_BACKTRACE=1 base100 -d                                                                                                                                             1:25 AM 101 ↵
thread 'main' panicked at 'attempt to subtract with overflow', src/main.rs:69:44
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic_new
   6: std::panicking::begin_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::panicking::panic
  10: base100::main::{{closure}}
             at src/main.rs:69
...

[86me]

I see what you mean about the newline character, because when I added some debug statements to see what was happening, the last character is either \n, or \u{0} (with echo -n). I'm not very proficient with rust, so I'm having a ridiculously hard time trying to trim that last character off of decoded_str. Some examples:

╰ % echo "test"|./base100|./base100 -d                                                    8:53 PM 101 ↵
ch: 128107
ch - base: 116
ch: 128092
ch - base: 101
ch: 128106
ch - base: 115
ch: 128107
ch - base: 116
ch: 128001
ch - base: 10
ch: 0
thread 'main' panicked at 'attempt to subtract with overflow', src/main.rs:71:65
note: Run with `RUST_BACKTRACE=1` for a backtrace.

The newline seems to be subtracting fine, it's the unicode NUL character that's causing it to crash:

╰ % echo -n "test"|./base100|./base100 -d                                                 8:53 PM 101 ↵
ch: 128107
ch - base: 116
ch: 128092
ch - base: 101
ch: 128106
ch - base: 115
ch: 128107
ch - base: 116
ch: 0
thread 'main' panicked at 'attempt to subtract with overflow', src/main.rs:71:65
note: Run with `RUST_BACKTRACE=1` for a backtrace.

rustc 1.20.0 cargo 0.21.0

[86me]

Figured it out. Adding .filter(|ch| *ch as u32 > 10) above the call to map() fixes the issue.

[AdamNiederer]

That slows it down by almost 2x, from my readings. I just pushed dd2dc16351c6fac443c56b9a0d1ffb72c4712f2b; that should fix your issue and speed it up by around 20% on SSE-enabled CPUs.