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. -- Torbjörn _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
