I mean not to put too fine a point on it but isn't GMP used for authentication on a certain major linux desktop?
I presume those guys thought of this, and statically link, or that I am just wrong. Bill. On 25 Aug, 16:15, Bill Hart <goodwillh...@googlemail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---