Re: functions returning int with 'l' protocodes.

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

On Tue, 15 Oct 2002, Bill Allombert wrote:

> On Tue, 10 Sep 2002, Bill Allombert wrote:
> > Comparison functions usually return an `int' not a `long'.
> > This is correct since they always returns 0, 1 or -1.
> >
> > However some of them are available from GP, but there is
> > not protoype letter for int, so we use l instead.
> >
> > But this is wrong, since on 64bit mechines, int is 32 bit and
> > long 64bit.
> >
> > On ia64 PARI compiled with gcc -g (for all versions) do not pass
> > the bench, because in some cases, (int) -1 became (long) 2^32-1,
> > which is correct, since we have hid the cast from the compiler.
> >
> > FIx involves either add a new letter code for integers, or
> > `upgrade' all functions return int to long.
> > The second option seems better.
>
> So Karim, what do you prefer ?

The whole point of the install() machinery is to be able to include as many
external routines as possible without recompiling the library. Since there's
no reason to forbid 'int' return types, I'd rather add a new parser code. And
introduce RET_INT, RET_LONG, RET_VOID as per your patch proposal.

> For the stable version: the only way we can keep the ABI safe is to add a
> new array with the information about the output type (long or int) and to
> cast correctly when needed. Unfortunately this may slow GP down and is a
> bit ugly. Also this will be an addendum to the API, but we already done it
> by adding the PARI_VERSION definition, but this is not as bad, since
> precisely the PARI_VERSION will allows programs to know at compile time if
> the new array is there.

I don't think it's worth worrying about the stable version now. This problem
has been around since ~ 1995 and nobody ever complained, so there's no
urgency to fix it there, esp. in an ugly way.

In fact I'd rather finalize the GMP port and the new file setup ( proper
public/private headers, split files, description database to synchronize GP
routines prototypes for GP, PARI, gp2c and Math::Pari). And then try to
stabilize it all and start a beta cycle. 2.1.0 has been out for two years
now, and the 2.2.* branch is so much better... (IMHO).

    Karim.
-- 
Karim Belabas                    Tel: (+33) (0)1 69 15 57 48
Dép. de Mathematiques, Bat. 425  Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud             Email: Karim.Belabas@math.u-psud.fr
F-91405 Orsay (France)           http://www.math.u-psud.fr/~belabas/
--
PARI/GP Home Page: http://www.parigp-home.de/