Future support for inttypes.h values

[Kevin Ryde]

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
        function calls.
      + 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
    compilers later.
    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.