Re: [RFC][PATCH v2] Add reallocarray function.

[Paul Eggert <eggert@cs.ucla.edu>]

Rüdiger Sonderfeld wrote:
> I wonder if there is any general interest or objections to adding the
> `reallocarray' function to glibc?

As an application developer I'm mildly interested if you can speed it 
up.  GNU apps like 'ls', 'grep', etc. that need such a function 
typically use Gnulib's xnrealloc, which has the same signature and 
nearly the same behavior as reallocarray.  xnrealloc and reallocarray's 
behaviors differ in two subtle ways, though.  First, xnrealloc's 2nd arg 
must be nonzero; this avoids a runtime check for zero so it's a bit 
faster (xnrealloc is an inline function so much of the overflow test's 
work can typically be done at compile-time).  Second, xnrealloc's result 
is guaranteed to be non-NULL if its first arg is nonzero; this lets the 
calling code be simpler.

We could alter xnrealloc to be a simple wrapper for reallocarray if 
reallocarray is available.  With the current reallocarray 
implementation, though, this might not be worth the trouble, because I 
suspect xnrealloc's test for overflow is faster than reallocarray's in 
the typical case where the last argument is a constant.  If you could 
fix reallocarray to use the equivalent of __builtin_umul_overflow, 
though, this objection would be removed and it would make sense for 
xnrealloc to be a wrapper for reallocarray if available.