Re: gmp 2.0.2 test buglet

[Kevin Ryde]

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.