error: don't try to 1-index the usize::MAXth position in a string

[apoelstra]

There are a lot of ways we can go about fixing this. Project Loupe advocates always casting to u128. If we want to do that I guess we can do it specifically for usize::MAX.

Alternately we can use a saturating increment, which would result in wrong output.

I choose to just write [usize overflow]. Even though this is supposed to be a use-facing error, the only way to hit this case is if the programmer is doing something crazy, so it seems worthwhile to handle this specific case in a programmer-centric way.

I don't feel strongly about this. Happy to take any other approach.

Fixes https://github.com/project-loupe/audit-hex-conservative/issues/4

[apoelstra]

On a1d869b successfully ran local tests

[Kixunil]

This can realistically only happen in the offset method, so I suggest adding an assert there to prevent it reaching usize::MAX.

[Kixunil]

Or maybe just write out 18446744073709551616th for this case. There's no point programatically adding 1 if you already know the value.

(I guess I prefer not dealing with invariant if we can avoid it.)

[apoelstra]

And change the docs of DecodeFixedLengthBytesError::offset to say that it'll panic if you pass it usize::MAX?

[Kixunil]

My preferred solution is to special case usize::MAX by printing the statically-known number and update the docs of offset to say warn that the operation may overflow if you pass in crazy numbers. That way we won't have to make sure the error type maintains a funny invariant. But if we're going to maintain an invariant then we really should document it of course.

[apoelstra]

Unfortunately we don't know the value because the size of usize is system dependent :). We could special-case 32 and 64 and add a fallback for others of course.

But whatever our solution, I'd prefer to avoid the funny invariant.

[Kixunil]

LOL, forgetting about that was quite a brain fart.

Since a cfg for usize doesn't exist, we need this:

const USIZE_MAX_PLUS_ONE: &str = {
    match core::mem::size_of::<usize>() {
        8 => "18446744073709551616th"
        4 => "4294967296th",
        2 => "65536th",
        _ => panic!("unsupported architecture"),
    }
};

(Weird, I jut noticed all the numbers end with 6. 🤯 )

[apoelstra]

I'm just gonna go with this. Though I'll replace the panic with some dummy text because why not.

[Kixunil]

ACK d817255

[apoelstra]

On d817255 successfully ran local tests