I think by "this capability" I mean the capability GMP/MPIR has of
allowing user code to supply a memory manager.
I mean, if that is global, doesn't it imply that user code can spy on
the memory of other user code, say when it comes up for realloc?
And it is also potentially possible for one process to crash another
by controlling its memory allocation.
Maybe I completely misunderstand what "this capability" is all about.
Bill.
On 24 Aug, 23:54, Nils Bruin <nbr...@sfu.ca> wrote:
> On Aug 24, 2:44 pm, Bill Hart <goodwillh...@googlemail.com> wrote:
>
>
>
>
>
> > void
> > mp_set_memory_functions (void *(*alloc_func) (size_t),
> > void *(*realloc_func) (void *, size_t, size_t),
> > void (*free_func) (void *, size_t))
> > {
> > if (alloc_func == 0)
> > alloc_func = __gmp_default_allocate;
> > if (realloc_func == 0)
> > realloc_func = __gmp_default_reallocate;
> > if (free_func == 0)
> > free_func = __gmp_default_free;
>
> > __gmp_allocate_func = alloc_func;
> > __gmp_reallocate_func = realloc_func;
> > __gmp_free_func = free_func;
>
> > }
>
> > Not very extensive huh. I actually don't see a solution to this
> > problem that involves mpir. In fact I think this is a security issue
> > and I don't think this capability should even exist.
>
> I do not understand what you mean, partially because I don't
> understand what you mean by "this capability". If you think it's
> relevant, would you mind explaining a little more elaborately?
>
> In other news, I now see that my assumptions about ECLs usage of GMP
> do not hold at all. They are depending on GMP claiming memory for them
> almost everywhere.
> However, a bignum in C is immutable, so after its creation it does not
> change value anymore. So it might actually make sense to preallocate
> bignums as
> [mp_size, mp_d, <pointer to limb[0]>, mp_alloc, limb[0], limb
> [1], ... , limb[mp_alloc-1]]
> i.e., put the limbs straight after the mpz_t. That way, creating a
> bignum only takes one alloc, instead of two.
>
> We would have to ensure that enough limbs are allocated to upon
> creation. One way to do that would be to let GMP create the result in
> a temporary variable, copy over the limbs into the bignum and call
> gmp_free on the temporary variable (or keep the temp around for the
> next time). That would always incur an extra copy, but the current
> implementation in ECL does something along those lines (but not
> always).
>
> Does GMP have routines somewhere that predict how many limbs the sum,
> difference, product, exponential of an answer going to need? Naively,
> I would think:
>
> nlimbs(a+b) <= nlimbs(a)+nlimbs(b)+1
> nlimbs(a*b) <= nlimbs(a)*nlimbs(b)
>
> etc.
>
> Is that correct? Or do certain optimizations/weird platforms mean that
> these naive bounds can be wrong?
>
> I think it should be possible to rewrite the bignums of ECL such that
> the only "mpz_t"s that GMP allocates/reallocates are "registers",
> i.e., temporary variables that do not need to be garbage collected,and
> if we can predict the sizes beforehand, we may even be able to gain
> some efficiency by eliminating some uses of "registers" in the current
> code.
> That might make the change a little more palatable to the ECL
> maintainers. It would also mean that the "embeddability" of ECL would
> increase a bit by not requiring that ECL administer the GMP's memory
> allocation.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
