use size_t where appropriate

[minad]

In particular in mp_int. 2.0 refactoring!

[dmitry-lipetsk]

https://github.com/dmitry-lipetsk/libtommath-for-ibprovider--set01/blob/master/ibp_external__libtommatch_set01__tommath.h

:)

[minad]

@dmitry-lipetsk interesting! Are there issues/mistakes you found while doing the porting? You mention that in your readme. It would be nice to backport them here.

[dmitry-lipetsk]

If I remember correcly, I described all detected issues here (in Issues).

[minad]

Ok thank you!

[czurnieden]

Are there plans to tackle the carefully ignored integer overflow in mp_count_bits? That problem is theoretical only for 32/64-bit large size_t but not so much for the LibCs for some 16-bit architectures with 16-bit size_t (e.g.: AVR Libc ) with enough memory.

Adding an overflow check in mp_count_bits is not a problem, signaling the error is. We could return SIZE_MAX (as the error MP_SOF maybe?) which is safe because (sizeof(size_t) * CHAR_BIT)/MP_DIGIT_BIT < SIZE_MAX for all of the current MP_nBIT sizes.

E.g.: something like this:

/* Useful elsewhere, too? */
#define MP_USED_MAX (SIZE_MAX/MP_DIGIT_BIT)

size_t mp_count_bits(const mp_int *a)
{
   size_t   r;
   mp_digit q;

   /* shortcut */
   if (MP_IS_ZERO(a)) {
      return 0;
   }

   /* get number of digits and add that */
   r = a->used;
   if (r > MP_USED_MAX) {
      return SIZE_MAX /*MP_SOF*/;
   }
   r = (r - 1) * MP_DIGIT_BIT;

   /* take the last digit and count the bits in it */
   q = a->dp[a->used - 1];
   while (q > 0u) {
      ++r;
      q >>= 1u;
   }
   return r;
}

But is it worth the hassle? I don't know.

[nijtmans]

I don't think this is a problem at all. Reasoning: The problem arises when a->used > MP_USED_MAX. Well, a->used is always smaller than a->alloc (since you cannot use more bytes than you allocate). So, the problem can only exist when a->alloc > MP_USED_MAX. This means more bytes than MP_USED_MAX*MP_DIGIT_BIT (= SIZE_MAX) were allocated for the mp_int. That's impossible, since such a malloc will fail. Conclusion: This situation can simply never happen if a was initialised by libtommath.

[nijtmans]

Hm ... Thinking more about it, yes it can happen. I forgot the difference between bytes/bits. As soon as the mp_int occupies more than 1/8th of the maximum addressable memory, r might overflow.

[minad]

We could always check before malloc that size*digitbits does not overflow?

[nijtmans]

I prefer your original proposal: Checking for it and returning SIZE_MAX in case of overflow.

[nijtmans]

..... or make r an "unsigned long long" and return that. No machine can allocate that much memory

[minad]

Or simply return mp_err.

[czurnieden]

Or simply return mp_err.

Would work only now with int (just return something negative) but not later with size_t which is unsigned according to the standard.

Or change the function to something like e.g.: mp_err mp_count_bits(mp_int *a, size_t *size) ?

[minad]

Change the function

[czurnieden]

Change the function

Started that proces in #391
Might take some time to end it, it is used at a lot of places ;-)