Karim BELABAS on Wed, 12 Jun 2002 19:44:52 +0200 (MEST) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
gpmem_t |
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 ? Karim. 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 like 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/