In GMP, will passing a multiple-precision type as both a return argument and an operand argument work? -

I have a problem in which I need to be prepared to explore large amounts of numbers 3 ^ (n * N) I have been advised by this community to use GMP for many communities. Since I have to re-run through the number one number at a time, so I have to move my counter easily.

My impulse is to use "mpz_add_ui" (my_counter, my_counter, 1UL) ", but I'm worried that as a return counter to passing my counter and being corrupted as a result of an addend Could be the reason for this. If the function calculates the answer, then this blank operator changes, then this number can change in such a way that the answer will go wrong. It is unlikely that increment will be the cause of any problem, but what about adding two big mpz_t? Or multiplication, or even exponentiation? For documentation either there is nothing to calm or confirm my concerns. I have tried to see the source code, but the combination of macros, sparse comments and leap from one file encourages me to conclude that I'm not yet a programmer to follow.

To be safe, I have written a function that represents the format, I definitely do certain work, but I will refuse too much because I believe it is my program Will slow down:

  zero mpz_increment (Mpz_t) {mpz_t temp; Mpz_init (temporary); Mpz_add_ui (temp, a, 1UL); Mpz_set (a, temp); Mpz_clear (temporary); }  

So, my question is, is it safe to pass a multi-precision type as a return logic and an operand in a GMP arithmetic function, or by doing so Will result in contaminated results?

Yes, you can find similar examples of input and output parameters. This is clearly stated in the "section" of the document:

GMP allows you to use the same variable for both input and output in a call. For example, the main function for the integer multiplication, mpz_mul, can be used for class x and keep the result back in x with

  mpz_mul (x, x, x) Can;