Future support for inttypes.h values
user42 at zip.com.au
Mon Apr 26 03:27:45 CEST 2004
Stephen Torri <storri at cse.wustl.edu> writes:
> I was wondering what the
> future support was for this? What would the level of difficulty be for
> adding this (e.g. easy, medium, hard)?
Notes from doc/tasks.html below. I think supporting long long on gcc,
and worrying about other compilers later would be a good option, it
helps free software and doesn't hurt portability.
Since you can always use mpz_import and mpz_export, there's nothing
actually lost by not having long long etc functions though.
* mpz_get_ull, mpz_set_ull, mpz_get_sll, mpz_get_sll: Conversions for long
long. These would aid interoperability, though a mixture of GMP and long
long would probably not be too common. Since long long is not always
available (it's in C99 and GCC though), disadvantages of using long long
in libgmp.a would be
+ Library contents vary according to the build compiler.
+ gmp.h would need an ugly #ifdef block to decide if the application
compiler could take the long long prototypes.
+ Some sort of LIBGMP_HAS_LONGLONG might be wanted to indicate whether
the functions are available. (Applications using autoconf could probe
the library too.)
It'd be possible to defer the need for long long to application compile
time, by having something like mpz_set_2ui called with two halves of a
long long. Disadvantages of this would be,
+ Bigger code in the application, though perhaps not if a long long is
normally passed as two halves anyway.
+ mpz_get_ull would be a rather big inline, or would have to be two
+ mpz_get_sll would be a worse inline, and would put the treatment of
-0x10..00 into applications (see mpz_get_si correctness above).
+ Although having libgmp.a independent of the build compiler is nice, it
sort of sacrifices the capabilities of a good compiler to uniformity
with inferior ones.
Plain use of long long is probably the lesser evil, if only because it
makes best use of gcc. In fact perhaps it would suffice to guarantee long
long conversions only when using GCC for both application and library.
That would cover free software, and we can worry about selected vendor
In C++ the situation is probably clearer, we demand fairly recent C++ so
long long should be available always. We'd probably prefer to have the C
and C++ the same in respect of long long support, but it would be possible
to have it unconditionally in gmpxx.h, by some means or another.
More information about the gmp-devel