Re: gmp 2.0.2 test buglet

[der Mouse]

>>>> I've been using GMP 2.0.2 [...]
>>> GMP 2 is obolete.  Please upgrade to GMP 3.1.1.
>> 2.0.2 is known to work with the programs I use it with.  If and when
>> I encounter a *functionality* lack, I may upgrade.  Until then, "if
>> it ain't broke, don't fix it".
> What an old-fashioned attitude in these days when people switch Linux
> kernel of their GNU/Linux systems on a daily basis!  :-)

:-)  I guess I'm just old-fashioned in preferring to spend my time
playing with stuff I enjoy rather than playing heatseeker with the
support libraries....

>> But maybe 3.1.1 does fix some of the problems I've had with 2.0.2.
>> Does it fix the t-get_d problem I mentioned?  Or any of these:
> If you want to know which of your issues GMP 3 addresses, then I
> guess you need to download it and find out.

Perhaps someday I will.  For the time being, 2.0.2 isn't broken enough
for the perceived probable effort of switching to outweigh the
perceived probable effort of fixing 2.0.2.

> Besides, your list is not really serious, it is merely an outcry of
> frustration.

To an extent; my mentioning it here largely was.  But everything on
there is something I consider a bug and in my work would fix, and 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.)

>> - All the advertised types are really arrays(!), thereby making it
>>   impossible to, for example, assign a variable of type mpz_t to
>>   another such(!!), and this being completely undocumented(!!!)?

> Terrible isn't it!

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.

> But you're not correct that it is impossible to assign a mpz_t
> variable from another such variable.  It is clearly written in the
> manual how to perform such assignment.

It may be possible to call a function to perform the conceptual
operation of "copy value".  It isn't possible to do the operation C
calls "assignment".

> But you cannot syntactically use `=' for assignment and thus cause
> copying of pointers and malloc havoc, if that is what you mean!

You mean like the havoc caused by

        mpz_t v[...];
        ...
        if (...)
         { mpz_t tmp;
           tmp = v[i];
           v[i] = v[j];
           v[j] = tmp;
         }

(except C won't let you do it)?

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).

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.

Since I tripped over this I've completely ignored mpz_t, mpn_t, etc,
and used the underlying types, MP_INT, MP_RAT, etc.  That way I don't
appear to be doing call-by-reference in a call-by-value language and
I'm not bitten by momentarily forgetting that something declared
without [ ] is nevertheless actually an array.  I just have to convert
the documentation mentally as I read it, and if I forget that the
compiler will kvetch.

                                        der Mouse

                               address@hidden
                     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B