Currently both from_base_be and from_base_le accept more digits then can fit in the target Uint. This leads to extra iteration/recursion. If all extra digits are 0, there is unbounded extra iteration/recursion, which results in degenerate cases:

I'd consider this intentional. Leading zeros are supported by the base convertor as they make mathematical sense.

If you feed it an infinite string of zeros than I'd expect it to take infinite time. That's IMO not a bug but a consequence of the inversion of control created by Rust's iterators. If you give it an iterator that panics it will panic. If you give it an iterator that launches rockets, it will launch rockets.

We can look into optimizing the leading zero case. Handling them should be O(n) time, O(1) space.

It makes sense from a mathematical perspective. On the other hand, we can infer that it is never a sane user's intention to trigger this behavior. We also know that after the max digits is reached, any further non-zero digit is guaranteed to cause an overflow. It seems like we can/should use this knowledge to prevent or handle invalid use of the API

There are sane usecase where this would be useful, as it's pretty common to store numbers with an excessive amount of leading zeros as a way of padding. For example Solidity's ABI likes to store U160 padded up to U256. It would be nice if we can parse the U160 directly from the whole hex string and have it handle overflow correctly. The alternative would be an intermediate U256 and try_into, or messing with substrings and forgetting to check that the lead is indeed zero.

I'm proposing an alternate implementation of from_base_le that won't run out of memory/stack in #293 .

The sane usecases are bounded at (generously) 100 extra digits, and there's no sane usecase for infinitely looping. It's never good behavior for a library to hang indefinitely on valid input

Maybe this is a place to use size_hint and error out if no upper bound is established?

Can you give me an example of a well-written rust library that puts similar bounds on user provided iterators? For example min from std also hangs:

fn main() {
    println!("{:?}", core::iter::repeat(0_u64).min());
}

And here it doesn't even need to hang, because it could short-circuit as soon as it sees u64::MIN. The functions in this PR have a more valid reason to continue as it can actually affect the outcome.

Generally I don't consider this infinite looping in the library. This is entirely on the user of the API and expectations should be that iterators will be consumed in full unless noted otherwise. This is not Haskell with lazy execution.

I do appreciate making APIs idiot-proof, but would not go as far as limit power users in what they can do.

closing as there's no pressing need and I don't have a good plan anyway :)