mpz_gcd_ext(NULL, ...)

[Niels Möller]

"Marco Bodrato" <bodrato at mail.dm.unipi.it> writes:

> While we are looking at gcdext, I propose a small change to save an
> allocation when t must be computed. Can you review it, to check if the
> size assumptions are safe?

Sorry, I haven't looked too closely at this code...

I guess it still allocates an extra limb for some arguments, which no
longer is required by mpn_gcdext.

>         PTR (&gtmp) = tmp_gp;
>         SIZ (&gtmp) = gsize;
>
>         PTR (&stmp) = tmp_sp;
>         SIZ (&stmp) = tmp_ssize;

This style makes my uneasy... I'd prefer to either use real
reallocatable mpz_t for destination operands, or use mpn functions
directly... But that's unrelated to this change.

You did one more thing in the committed change 84ce52f0d360:

--- a/mpz/gcdext.c	Tue Dec 13 19:20:31 2016 +0100
+++ b/mpz/gcdext.c	Sat Dec 17 21:26:50 2016 +0100
@@ -64,7 +64,7 @@ mpz_gcdext (mpz_ptr g, mpz_ptr s, mpz_pt
 
       if (g != NULL)
 	{
-	  gp = MPZ_REALLOC (g, asize);
+	  gp = MPZ_NEWALLOC (g, asize);
 	  MPN_COPY (gp, PTR (a), asize);
 	  SIZ (g) = asize;
 	}

That will break in case g == a, right? So we'd need to either keep
MPZ_REALLOC, or check for that special case. So I'm afraid the reuse
test doesn't hit this corner...

Regards, and Happy New Year,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.