[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gmp 2.0.2 test buglet
From: |
Kevin Ryde |
Subject: |
Re: gmp 2.0.2 test buglet |
Date: |
07 Dec 2000 07:06:31 +1000 |
User-agent: |
Gnus/5.0807 (Gnus v5.8.7) Emacs/20.5 |
der Mouse <address@hidden> writes:
> ...
> I would hope that some of them (such as the macppc stuff and the VAX
> s/ll/__ll/) would be things you would consider bugs too.
>
> But then, you no longer care about bugs in GMP 2, it seems. (Either
> that or you don't consider a coredump from "make check" a bug.)
The current changelog will reveal a fix has been applied for mpq/get_d
on vax. Report again if it still happens. (Bugs that still exist
will generate more interest! :)
> Yes, especially the last. I could see providing the array types for
> the sake of some kind of notational convenience (which is, I assume,
> why that was done in the first place). But I can't see failing to
> equally advertise the underlying type, and most especially can't see
> failing to document it.
The manual has been updated in 3.1.1 to mention this, and to describe
the semantics a bit more.
> You mean like the havoc caused by
>
> mpz_t v[...];
> ...
> if (...)
> { mpz_t tmp;
> tmp = v[i];
> v[i] = v[j];
> v[j] = tmp;
> }
mpz_swap (and other swaps) exist in 3.1.1.
> Actually, I first tripped over this in a different context, but I can't
> now recall just what. I think it had to do with function calls -
> perhaps I tried to declare a function returning mpz_t (or mpn_t or
> mpq_t or some such).
That's specifically warned against in the current manual.
> It is also unsettling, to say the least, to see a call-by-value
> language like C appearing to use call-by-reference semantics, as is
> done by the documented interface of practically all calls that have
> output arguments.
I think call by value would be difficult for any non-trivial type in C.