from gmp-bugs.
Il Ven, 27 Aprile 2018 7:21 am, Niels Möller ha scritto:
> "Marco Bodrato" <bodr...@mail.dm.unipi.it> writes:
>> Currently there's always at least one readable limb, so for instance
>> @code{mpz_get_ui} can fetch @code{_mp_d[0]} unconditionally (though its
>> value is then only wanted if @code{_mp_size} is non-zero).
>
> Maybe change "is only wanted if" to "is valid only if" or "is usable
> only if". At some point, I suffered the misunderstanding that _mp_size
> == 0 implies _mp_d[0] == 0, which isn't right.
Do you mean that we should underline that also with _mp_size == 0, any
limb above the size of the number is undefined?
> _mp_alloc == 0 and _mp_size != 0 is a read-only value, _mp_d is neither
> written, reallocated or freed by mpz functions. It must not be passed as
> destination argument to any mpz function. Should also link to docs for
> mpz_roinit_n and MPZ_ROINIT_N.
Currently, if an mpz_t is initialised with _roinit, it can be passed to
_clear or _clears with no errors. Should we document this? I think we
should.
Moreover, the various mpz_set_ functions should work smoothly too. And I'm
quite sure that any mpz function is able to "overwrite" an mpz_t that was
initialised with _roinit. I mean, the following code actually works:
int main(void)
{
mpz_t f0, f1, fn;
int n = 10;
mp_limb_t dummy = 1;
mpz_roinit_n (f0, &dummy, 1);
mpz_roinit_n (f1, &dummy, 1);
mpz_roinit_n (fn, &dummy, 0);
for(;--n;) {
mpz_add (fn, f0, f1);
mpz_swap (f0, f1);
mpz_swap (f1, fn);
}
gmp_printf ("%Zd\n", f1);
mpz_clears (f0, f1, fn, NULL);
}
Problems arise only when ones try to _update_ a value with an mpz function.
mpz_add (f0, f0, f1); mpz_swap (f0, f1); does not work...
Should we document this too. I think we should not.
Ĝis,
m
--
http://bodrato.it/papers/
_______________________________________________
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
