[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gmp 2.0.2 test buglet
From: |
der Mouse |
Subject: |
Re: gmp 2.0.2 test buglet |
Date: |
Wed, 6 Dec 2000 12:44:49 -0500 (EST) |
>>>> 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