Torbjorn Granlund wrote:
I started a page: http://gmplib.org/devel/incompatibility.html
We might want to classify incompatibilities as source, binary, and both.
I have not listed obsolete functions. The cost of retaining obsolete
function compatibility is very low; the temptation to
Ciao,
Il Lun, 4 Giugno 2012 6:32 pm, Torbjorn Granlund ha scritto:
Pedro Gimeno p.gim...@formauri.es writes:
Also, I seem to remember there were plans to make a new version of
mpz_nextprime accepting a random state and the number of M-R tests, and
of mpz_probab_prime_p accepting a
ni...@lysator.liu.se (Niels Möller) writes:
The old_size argument should be removed also from the free function, not
just realloc.
Fixed.
Add return value to mpz_sqrt, for consistency with mpz_root (assuming
such a flag can be returned very cheaply, which I think it can).
Added.
Torbjorn Granlund wrote:
Pedro Gimeno p.gim...@formauri.es writes:
My recollection is that gmp_errno was not thread-safe, not just
obsolete, and that that was a reason for getting rid of it.
Making some C error handling mechanism would be great, though. I am not
sure that's easy,
Torbjorn Granlund t...@gmplib.org writes:
Last time you suggested this, I think I asked you to explain how to do
with the multitude of multiply functions, which might need to store the
full n-limb value in a new large temp area, then copy its low n-1 limbs
to the target area.
One would have
On Mon, 4 Jun 2012, Torbjorn Granlund wrote:
Pedro Gimeno p.gim...@formauri.es writes:
My recollection is that gmp_errno was not thread-safe, not just
obsolete, and that that was a reason for getting rid of it.
If the main issue with gmp_errno is thread-safety, it should just become
Torbjorn Granlund t...@gmplib.org writes:
I know of only two C mechanims, either signals+handlers or setjmp+
longjmp.
I'm not entirely sure what type of errors you are considering handling
here? Memory allocation failures? Divide-by-zero? Something else?
It's possible to make errno-style
