[Gcl-devel] Re: TMP_ALLOC in mpn_mul_n

[Kevin Ryde]

Camm Maguire <address@hidden> writes:
>
> 2) Anyway, all of that is gcl's problem and not gmp's -- but what
>    about other systems using garbage collection?  The Boehm collector
>    is becoming more popular these days for example, and it relies on a
>    redirected malloc as well.

It reclaims blocks, but doesn't move anything does it?

>    Do you know of any areas off hand in which gmp would
>    assign a pointer variable, do some allocation, and then access the
>    original variable which then could be no longer valid?

That sort of thing is done almost everywhere.  GMP is typical C code,
when it mallocs one block and then mallocs another it expects the
first pointer to still be valid.

>    gmp doesn't save addresses statically anywhere, does it?

The old-style random number functions might be the only place doing
that.  Use the new style gmp_randstate_t instead.

>    In any case, it is
>    entirely possible that even if gmp does do the former, as long as the
>    address in question is held in a local variable on the C stack,
>    gcl's garbage collector will find and 'mark' it.

On the stack or in registers, as you'd expect from C code.  Oh, and
mpz_powm stores pointers to malloced blocks within another malloced
block, if that affects anything.

> 4) It sounds as if you might be aware of some prior conversation with
>    Dr. Schelter on these points.  Is such a conversation archived
>    anywhere? 

It started on bug-gmp, block movement was the only real stumbling
block, resulting in the patched multiply you've seen, and perhaps also
tweaks to mpz_setbit and mpz_clrbit.

> On Windows, we'll have to build and statically link our
> own version for the time being.

Other perverse systems might be similarly afflicted, AIX maybe, not
sure.