_mp_alloc vs ALLOC

Torbjorn Granlund tg at gmplib.org
Sat Jun 2 16:02:52 CEST 2012

I thought avoiding the copying was a good idea, but this thread has made
me less sure.  I suppose it will speed things up only for sizes > some
threshold, else slow things down.

If we follow the GMP principle of relative overhead, perhaps we should
not do this.

It is a shame that C provides such primitive allocation functions.  I'd
like a realloc with extend-at-the-end, extend-at-the-beginning, and with
an optional call-back copying function.  (Such a function could
translate data, such as internal pointers, or do nothing, or copy a
relevant data only.)

About GMP's compatibility:

I agree the current gmp realloc interface is broken, in particular in
the light that we don't adhere to it ourselves.  We could make a
documentation change where we say that the oldsize argument will be the
allocated size of it is known, else 0...

*If* we decide to break compatibility, we should not do it just because
we are bothered by an extra parameter that is mostly invisible.  But
perhaps we should build a list of incompatible things to fix, small and
large, and at some point decide change them all?  We could make a
subpage to the GMP devel web pages, "Things the developers think are
broken in GMP" with this list.


More information about the gmp-devel mailing list