Karim BELABAS on Wed, 12 Jun 2002 19:44:52 +0200 (MEST)

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]


There is a new type for libpari stack pointers, like 'avma', currently called
'gpmem_t' [ and currently typedef-ed to unsigned long ].

The name is ridiculous, and I'd like to change it to something decent before
documenting it. Currently I'm thinking of 'stack_ptr', but I'm not that
enthusiastic [ pari_stack_ptr is a bit long, and wrappers can do it for us if
namespace becomes an issue ].

Bill initially suggested 'unsigned long', since introducing countless new
types without a definite purpose would increase rather than reduce confusion.
I think we settled the matter (see below for the "definite purpose").

So, what about the name ?


PS: Rationale:

I did that change to clean up all the 'av = avma' kind of statements. After
applying a trivial perlscript to change most occurences of 'av*', 'tetpil',
'lbot', 'ltop', so as to change their type to 'gpmem_t'.

Then I temporarily typedef-ed gpmem_t to (void*) and got a large number of
Warnings from gcc, some of them corresponding to genuine bugs [ like signed /
unsigned comparison ]. I cleanup up by hand the others that had simply
escaped the script.

Of course, the new type remains compatible with the old 'unsigned long' (or
even older 'long') in any case. It's a way of marking clearly who does what
[ besides using "reserved" identifiers like 'av', 'tetpil', 'ltop', 'lbot',
which to the trained eye can't represent anything but stack pointers, just
like epsilon can't possibly go to infinity ]. The goal was to get rid of
declarations like [ pari.1.39.15:gen1.c:gadd() ],

    long tetpil,av1,l1,a1,a2,r1,r2,d,r,l2,co;

which were ubiquitous, and where tetpil, av1, l1 are stack pointers
(exclusively)  and l2 is an occasional stack pointer, depending on the code
branch taken (sometimes it was the degree of a polynomial). It would now look

    stack_ptr tetpil, av1, l1, l2;
    long a1, a2, r1, r2, d, r, co;

where good coding practice would forbid a 'stack_ptr' to represent anything
but a stack address, altough the compiler has no way of enforcing this since
we want backward compatibility. ( But nothing prevents temporarily
typedef-ing stack_ptr to (void*) if one wants to clean up some code. )
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/