Implementation of mp*_sgn()

[Roberto Bagnara]

On 11/04/11 18:13, Marc Glisse wrote:
> On Fri, 4 Nov 2011, Roberto Bagnara wrote:
>
>> /* Allow faster testing for negative, zero, and positive. */
>> #define mpz_sgn(Z) ((Z)->_mp_size < 0 ? -1 : (Z)->_mp_size > 0)
>> #define mpf_sgn(F) ((F)->_mp_size < 0 ? -1 : (F)->_mp_size > 0)
>> #define mpq_sgn(Q) ((Q)->_mp_num._mp_size < 0 ? -1 : (Q)->_mp_num._mp_size > 0)
>>
>> These macros possibly evaluate their arguments twice.
>
> The documentation omits the "possibly":
> "This function is actually implemented as a macro. It evaluates its argument multiple times."
>
> ;-)

Yes, the documentation is correct in reporting the limitation.
So implementing these (and possibly others) as inline functions would
remove the limitatoin and be a definite improvement.

>> Would you accept a patch that substitutes them with inline functions?
>
> (I can't speak for Torbjorn)
>
> I don't see much wrong with making it an inline function (note that
> in that case we need to instantiate and export it in libgmp). I
> doubt anyone relies on the fact that it is a macro.
>
> I am a bit surprised that it matters at all...

Well, function-like macros are generally better avoided.  In the
specific case, I have been bitten by mpz_sgn().  Yes, I did not read
the fine print carefully enough (but how many GMP users do that?).

> Why just those 3 and not all the other macros: mpz_odd, mpz_cmp_ui, etc?

One has to start from somewhere, but yes: I see no reason to keep
this kind of function-like macros in GMP.  Of course, I may be
missing something.
Thanks,

    Roberto

-- 
Prof. Roberto Bagnara
Applied Formal Methods Laboratory
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara at cs.unipr.it