This is the mail archive of the
mailing list for the glibc project.
Re: [RFC][PATCH v2] Add reallocarray function.
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: RÃdiger Sonderfeld <ruediger at c-plusplus dot de>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 20 May 2014 07:06:13 -0700
- Subject: Re: [RFC][PATCH v2] Add reallocarray function.
- Authentication-results: sourceware.org; auth=none
- References: <5379208F dot 8030000 at cs dot ucla dot edu> <2080621 dot 6fAB4UMNoY at descartes> <Pine dot LNX dot 4 dot 64 dot 1405191501120 dot 25418 at digraph dot polyomino dot org dot uk> <1605307 dot hPebLlPzHB at descartes>
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.