Description
Hello.
Please forgive my ignorance, but the radix documentation states that radices greater than 256 are prohibited, and radix 32 is unsupported.
It says higher radices are not supported to save cache space, but my understanding is that generalizing the function would not incur additional cache costs for the existing racides.
Would it be advantageous, then, to write a generic radix function, like
to_radix_2W<const W: usize> -> [i8; (256 + W - 1)/W + 1], or, if generic const expressions are permissible,
to_radix_2W<const W: usize> -> [i8; to_radix_2w_size_hint(W)]
Theres obviously the possibility that this introduces some side channel attack, but, if this is the case, could this be documented?
Even so, I think it would be safer to have an implementation for higher radices here, where it can be audited with everything else, than have every library user write their own, each with their own attack surfaces.
I want to be very careful about timing and cache vulnerabilities here particularly, but I also want larger radices, so I'm really not sure what to do here. Any advice would be appreciated. Thank you!