Currently limbs in MLUInt/MLInt are stored as big-endian, because that's how multi-limb algorithms are generally described in the literature (e.g. in TAOCP or Handbook of Applied Cryptography). Perhaps, little-endian would be a more convenient format - limbs are already little-endian (on most systems where this library actually works), and it will help visually compare MLUInt/MLInt numbers with builtin types, or initialize them with predefined constants.
Currently limbs in
MLUInt/MLIntare stored as big-endian, because that's how multi-limb algorithms are generally described in the literature (e.g. in TAOCP or Handbook of Applied Cryptography). Perhaps, little-endian would be a more convenient format - limbs are already little-endian (on most systems where this library actually works), and it will help visually compareMLUInt/MLIntnumbers with builtin types, or initialize them with predefined constants.