From and to bytes

[Phaiax]

Added Functions:

Int:
    pub fn estimate_num_base_digits(&self, base: u8) -> usize {
    pub fn minimal_buffer_size(&self) -> usize {
    pub fn write_u8_be_radix(&self, dst : &mut [u8], base : u8) -> Result<usize, BufferToSmallError>  {
    pub fn write_radix_callback<F: FnMut(u8)>(&self, base : u8, receiver: F) {
    pub fn write_big_endian_buffer(&self, dst : &mut [u8]) -> Result<usize, BufferToSmallError> {
    pub fn write_big_endian_buffer_align(&self, dst : &mut [u8]) -> Result<usize, BufferToSmallError> {
    pub unsafe fn from_u8_be_radix_unchecked(src: &[u8], base : u8) -> Result<Int, ParseIntError> {
    pub fn from_u8_be_radix(src: &[u8], base : u8) -> Result<Int, ParseIntError> {
    pub fn from_big_endian_slice(src: &[u8]) -> Int {
    pub fn leading_zeros(&self) -> u32 {

    fn iter<'a>(&'a self) -> LimbsIteratorState<'a> {
Limb:
    pub unsafe fn iter_raw_bytes<'a>(&'a self) -> LimbRawBytesIteratorState<'a> {

The iterators for the limbs may not be performant, but
they are only used in write_big_endian_buffer() if the target is a big endian system, and this functionality is untested because I do not have a big endian system and will panic! on big endian.

Lets discuss :)
#6

[arthurprs]

I think this is possibly over engineered, maybe it should just provide a way to serialize itself to a T: Write and read from a T: Read making sure it continues to works across major versions.

[ofek]

@Phaiax You've done great work here!

Do you think you could please open a separate PR that only provides support for from &[u8] and to Vec<u8>? We have great need for such functionality and a PR with surface that small will get merged very fast.

[Phaiax]

Not now, since I am in holiday for another 4 weeks. But then I guess I could. Am 30. April 2017 10:17:00 GMT+07:00 schrieb Ofek Lev <notifications@github.com>:

…

@Phaiax You've done great work here! Do you think you could please open a separate PR that only provides support for from &[u8] and to Vec<u8>? We have great need for such functionality and a PR with surface that small will get merged very fast. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #67 (comment)

[ofek]

That would be fantastic, thanks!

[rozbb]

Thank you for the contribution! These are a lot of changes. Could you explain the reasoning behind them?

1. What is the use case for these functions? When would you use these and not want to use from_str_radix and to_str_radix?

2. How does the byte encoding play with different limb sizes? If I have two 8-byte limbs
   L0[a b c d e f g h] L1[i j k l m n o p] and I encode it in little-endian, I'll get the byte sequence h g f e d c b a p o n m l k j i, right? Now if I send that byte sequence to another computer using little-endian with 4-byte limbs, that will get decoded as
   L0[e f g h] L1[a b c d] L2[m n o p] L3[i j k l] which is incorrect.