_mp_alloc vs ALLOC
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