Vincent Lefevre <vinc...@vinc17.net> writes: This is not properly documented, then. The manual says:
'mpz_add_ui', 'mpz_sub_ui', 'mpf_add_ui' and 'mpf_sub_ui' benefit from an in-place operation like 'mpz_add_ui(x,x,y)', since usually ^^^^^^^^^^^^^^^^^^ only one or two limbs of 'x' will need to be changed. The same applies to the full precision 'mpz_add' etc if 'y' is small. If 'y' is big then cache locality may be helped, but that's all. Since this should be an in-place operation (as there is no carry), an overflow is unexpected here. Overflow here is a result of the mathmatical result. Whether things are done "in place" or not is not part of it. But overflow might be flagged one limb too early for addition; instead of at 2^27-1 limbs for 32-bit hosts it might happen already at 2^27-2 limbs. I cannot say that's particularly bad. As it happens, overflow detetion for other cases is much more coarse, such as powering. -- Torbjörn Please encrypt, key id 0xC8601622 _______________________________________________ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs