support larger int types
tg at gmplib.org
Thu Oct 13 18:38:00 UTC 2016
Marc is spot on, I think.
We cannot play a surprise game with GMP users and GMP applications; GMP
version X.Y should have exactly one API, not an API which is affected by
whichever compiler happened to be used by the one who compiled GMP.
We actually do have a setter for your favourite type which your
application compiler might provide: mpz_import.
Having said that, I think we might have been too slow with requiring
newer compiler standards. For C, long long was introduced with ISO C 99
which now is 17 years; I think would could require that in the next
major release. I am not sure which C++ requires long long.
A separate question is whether we should provide every abstract integer
type in the stdlib printf spirit. I.e., should we have mpz_set_int,
mpz_set_uint, mpz_set_long, mpz_set_ulong, mpz_set_int32_t,
mpz_set_uint32_t, mpz_set_least_int32_t, mpz_set_uintmax, etc, etc? And
then the same for mpz_add_* and mpz_mul_*, etc.
That is doubtful, but not completely out of the question as long as we
can have just a small set of underlying routines in the actual library.
(I have a repo with some mpz_foo_uj and mpz_foo_sj functions which
accept unsigned long long and signed long long respectively. That
naming makes some sense in the light of the current naming scheme for
long parameters (_ui and _si) but it does not naturally extend if we
pull out all stops.)
Please encrypt, key id 0xC8601622
More information about the gmp-discuss