On Aug 27, 4:06 am, Nils Bruin <nbr...@sfu.ca> wrote: > mpz_init(&c) > mpz_add(&c,&a,&b) > d=ecl_alloc( (c->_mp_size )*sizeof(limb)) > memcpy(d,c->_mp_alloc,c->_mp_size * sizeof(limb)) > r=ecl_alloc(sizeof(mpz_t)) > r->_mp_size = c->_mp_size > r->_mp_d = d > r->_mp_alloc = c ->_mp_size > mpz_clear(&c) > now we have our result r and all memory that GMP allocated has been > released again, > as long as we have the guarantee that GMP won't do a realloc on either > a or b. If GMP won't guarantee even that, then we basically have to > copy the operands into temps as well.
Exactly. The point, which I did not make clear enough, is not that we know the size of the output, but that we DO HAVE the output. All intermediate and final computations are always stored in integers that are allocated by whatever routine GMP is using for allocation. ECL will not clobber that. Instead, the output will be just saved -- more or less as Nils showed, but in a much simpler way -- using our own allocation routines. mp_set_memory_functions() will never be called by ECL. The only thing we need is a guarantee that mpz_add and similar routines will not reallocate A and B -- I would say it must not (otherwise what is the point of a three argument mpz_add), but it does not hurt asking at the MPIR / GMP mailing lists. I am right now on holidays, but I will try to introduce the appropriate fixes in ECL during the coming days. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
