On Thursday 27 August 2009 03:43:52 Nils Bruin wrote: > On Aug 26, 7:06 pm, Nils Bruin <nbr...@sfu.ca> wrote: > > OK, so r and d would probably get allocated using > > mpz_t *r > mp_ptr d > r = (mpz_t) ecl_alloc(sizeof(mpz_t)+(c->_mp_size )*sizeof(limb)) > d = (mp_ptr) (r+1) > r->_mp_size = c->_mp_size > r->_mp_d = d > r->_mp_alloc = c ->_mp_size > > Looking at the code of mpz_array_init, it seems that for GMP, *r > should pretty much look like an mpz_t > coming from an mpz_array_init. From the documentation there: > > The space allocated to each integer by this function will not be > automatically increased, unlike the normal mpz_init, so an application > must ensure it is sufficient for any value stored. The following space > requirements apply to various routines, > > * mpz_abs, mpz_neg, mpz_set, mpz_set_si and mpz_set_ui need room > for the value they store. > * mpz_add, mpz_add_ui, mpz_sub and mpz_sub_ui need room for the > larger of the two operands, plus an extra mp_bits_per_limb. > * mpz_mul, mpz_mul_ui and mpz_mul_ui need room for the sum of the > number of bits in their operands, but each rounded up to a multiple of > mp_bits_per_limb. > * mpz_swap can be used between two array variables, but not > between an array and a normal variable. > > For other functions, or if in doubt, the suggestion is to calculate in > a regular mpz_init variable and copy the result to an array variable > with mpz_set. > > So it seems that GMP makes storage guarantees after all (oddly, the > bit operations have no guarantee. My guess is that they were just > overlooked). This means we should be fine. I wonder how GMP recognizes > the difference between a variable from mpz_init and one from > mpz_array_init in order to decide whether to do a realloc.
GMP can not tell the difference, this is not a safe function to use and it has been depreciated in MPIR . Notice the "or if in doubt" above , GMP does not guarantee it either. > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
