seq: format_float_shortest panic when printing absurdly large exponents

[drinkcat]

While playing with inputs at the edge of maximum possible exponents:

RUST_BACKTRACE=1 cargo run -p uu_seq -- -f "%g" 1e9223372036854775806 1e9223372036854775806 inf
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.18s
     Running `target/debug/seq -f '%g' 1e9223372036854775806 1e9223372036854775806 inf`

thread 'main' panicked at src/uucore/src/lib/features/format/num_format.rs:467:20:
attempt to add with overflow
stack backtrace:
   3: uucore::features::format::num_format::format_float_shortest
             at ./src/uucore/src/lib/features/format/num_format.rs:467:20
   4: <uucore::features::format::num_format::Float as uucore::features::format::num_format::Formatter<&uucore::features::format::extendedbigdecimal::ExtendedBigDecimal>>::fmt
             at ./src/uucore/src/lib/features/format/num_format.rs:278:21
   5: uucore::features::format::Format<F,T>::fmt
             at ./src/uucore/src/lib/features/format/mod.rs:383:9
   6: uu_seq::print_seq
             at ./src/uu/seq/src/seq.rs:265:9
   7: uu_seq::uumain::uumain
             at ./src/uu/seq/src/seq.rs:185:18
   8: uu_seq::uumain
             at ./src/uu/seq/src/seq.rs:88:1
   9: seq::main
             at ./src/uucore/src/lib/lib.rs:157:24
  10: core::ops::function::FnOnce::call_once
             at /home/drinkcat/nobackup/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
1e+9223372036854775806
2e+9223372036854775806
3e+9223372036854775806
4e+9223372036854775806
5e+9223372036854775806
6e+9223372036854775806
7e+9223372036854775806
8e+9223372036854775806
9e+9223372036854775806

%e has similar problems:

RUST_BACKTRACE=1 cargo run -p uu_seq -- -f "%e" 1e9223372036854775807 1e9223372036854775807 inf
thread 'main' panicked at src/uucore/src/lib/features/format/num_format.rs:410:20:
attempt to add with overflow
stack backtrace:
...
   3: uucore::features::format::num_format::format_float_scientific

[JadenMajid]

When I run seq with regular utils I get the following

$ seq -f '%g' 1e9223372036854775806 1e9223372036854775806 inf
seq: invalid floating point argument: ‘1e9223372036854775806’
Try 'seq --help' for more information.

Here's the fn signature for format_float_shortest()

fn format_float_shortest(
    bd: &BigDecimal,
    precision: Option<usize>,
    case: Case,
    force_decimal: ForceDecimal,
) -> String {

I feel like I'm missing something...
The fn can only return strings but it looks like an Option or Result type should be here instead; Is there some sort of promise to fmt that numbers inputted are valid?
or should there just be some simpler error bounds check on seq on initial parse to make sure the inputs make sense?

Thanks!

[drinkcat]

For your first point, yes, GNU seq supports a much more limited range only. Tried to document here, still WIP: #7641. Whenever possible, I feel we should not constraint the range more than needed.

The specific problem here is that the next number in the sequence:

1e+9223372036854775806
...
9e+9223372036854775806

Would be 1e+9223372036854775807. The number fits into a BigDecimal (I guess it's 10 with scale -9223372036854775806 or something), but the print fails as the exponent overflows an i64 (not sure exactly where this fails)?

For your second point, unless we find a simple way to print the exponent correctly (I think that might not be easy). I feel like we could just print inf in that case. That's similar to how floating points end up overflowing, and similar to how seq -f "%g" 1000e4926 1000e4926 inf behaves (it fairly quickly goes to infinity).