Conversation
…ementation of encrypt/decrypt
… implementation for sketch and discussion only)
Co-authored-by: Tony Arcieri <bascule@gmail.com>
| fn num_traits() { | ||
| const TEST: Wrapping<U64> = Wrapping(U64::from_u64(0x0011223344556677)); | ||
|
|
||
| assures_num(TEST) |
There was a problem hiding this comment.
My logic here is: Num is implemented for Wrapping<T> where ... so that we're implementing it for the minimally restricted type, but we want to assure that it works for Wrapping<Uint<Limbs>>, so this code assures it.
I'm not sure if there's a better way of checking this.
| { | ||
| type FromStrRadixErr = (); | ||
|
|
||
| fn from_str_radix(str: &str, radix: u32) -> Result<Self, Self::FromStrRadixErr> { |
There was a problem hiding this comment.
How do we want to handle this?
Obviously this is unimplemented logic for this crate, and I'm not sure whether we want to support this (or, for example, return an error for any radix other than 2, 10 or 16.)
num-bigint's implementation is complex, but I could copy it if that's the way to go.
My thoughts are to actually to use from_str_radix() implementation of u32 and u64, that is, to parse limb-by-limb and sum them up.
| { | ||
| type Output = Wrapping<T>; | ||
|
|
||
| fn div(self, rhs: Wrapping<T>) -> Self::Output { |
There was a problem hiding this comment.
This and rem panics in case of division by zero.
This is the intended behavior of this crate, but I'm not sure that "this is the right panic" - i.e. now we'll panic on unwrap()ping of NonZero on zero, and the panic message might not be ideal; should I instead assert_ne(rhs, T::Zero) instead?
|
@tarcieri please see and respond to my comments so I can proceed |
|
#433 covers quite a bit of this |
|
Closing in favor of #433. Please open a new PR if you would like additional support which wasn't covered there. |
2 participants
Resolves #158