Question about mpz_clear

Geoff Thorpe geoff@geoffthorpe.net
Thu, 19 Jun 2003 11:56:54 -0400


On June 19, 2003 04:49 am, Michel Bardiaux wrote:
> Kevin Ryde wrote:
> > "Eric M. Hopper" <hopper@omnifarious.org> writes:
> >>Does this clear the memory associated with a given variable zeroed?
> >
> > No.
> >
> >>Is there an easy way to make sure it is?
> >
> > mp_set_memory_functions will let you have your own free function.
>
> I am having a slight problem with that. I have ascertained that I often
> have a lot of mpsomething with rather short limbs; it would be
> efficient to store the limbs contiguous to the 'enveloppe' data;
> unfortunately, the free function would then require more info than just
> the limb pointer. Is it conceivable to change the library for that? I
> might do it, but am not keen on starting a modif that would not be
> accepted in the official tree...

Can't you handle this from your malloc callback by setting some meta data 
as a fixed-size memory header? Ie. your malloc callback allocates an 
extra few bytes than it was asked for, stores "meta" information in the 
first few bytes, then returns a pointer to the first (aligned) byte after 
the meta information. The free (or realloc) callback simply has to 
subtract the same number of bytes off the pointer it is called with to 
get to that meta information. This allows you to do memory pooling, and 
any number of other nifty things. It also explodes in curious and 
fascinating new ways if there's any pointer arithmetic bugs in the 
library - ie. check your app with valgrind (without setting the memory 
callbacks) if anything starts going badly.

Using headers on all allocated pointers you return from your malloc 
callback is is a standard trick when the application or library assumes 
global memory callbacks with the standard libc prototypes. Be warned 
however that asking a programmer to make this (a) feature-rich and (b) 
thread-safe is generally considered "cruel and unusual" punishment.

> When that happens, is it not just the pointer data that is on the
> stack, with the limbs *always* in the malloc arena? (Of course my
> proposal would invalidate that!)

IIRC, one or two of the stack-happy functions in GMP will also alloca() 
limb data, but no doubt you'll get a definitive answer from someone else 
(or the source). If this is the case, and that's a problem, I would 
expect there to be some configuration trick to disable the use of the 
stack for this sort of thing? Good luck.

Cheers,
Geoff

-- 
Geoff Thorpe
geoff@geoffthorpe.net
http://www.geoffthorpe.net/