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: Wed, 21 May 2014 20:59:47 -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> <1605307 dot hPebLlPzHB at descartes> <537B6155 dot 6070104 at cs dot ucla dot edu> <2187944 dot g1p5OTczzC at descartes>
RÃdiger Sonderfeld wrote:
What happens if the 2nd arg is zero in a call to `xnrealloc'?
Undefined behavior. Agreed, this isn't suitable for reallocarray.
How can `xnrealloc' guarantee that the result will be non-NULL?
It tests realloc's result and calls a _Noreturn function if it's null.
Again, this is fine for Gnulib but not suitable for reallocarray -- we'd
keep this part in the Gnulib wrapper.
Is there active work done on those overflow checks in GCC?
The last message I know on the topic was last month. Sort of active, I
guess. <https://gcc.gnu.org/ml/gcc/2014-04/msg00194.html> Perhaps
someone should ping the GCC list.
While we're on the subject, there was a proposal last October to add
saturated arithmetic to glibc internals; see, e.g.,
Presumably this arithmetic could use these builtins too.
this might be something gnulib could provide (if it hasn't something like that already).
gnulib has several things like that already, which could be tuned to use
__builtin_umul_overflow if available:
* intprops.h's INT_MULTIPLY_OVERFLOW (A, B) returns true if multiplying
the integers A and B would overflow. It works for any combination of
integer types, so in this sense it's handier than __builtin_umul_overflow.
* xsize.h's xtimes uses saturated arithmetic to multiply size_t values,
and needs to check for overflow.
* xalloc-oversized.h's xalloc_oversized checks for overflow in size_t
multiplication, with the special case that SIZE_MAX represents a
previously-overflowed computation (e.g., from xtimes).
Perhaps we could add an MUL_OVERFLOW (A, B, PRESULT) macro to intprops.h
(that uses __builtin_umul_overflow/__builtin_ulmul_overflow/etc.) if
available) so that applications could use the builtins more directly if
they prefer. It's not clear how useful that would be, though.