Why was the reallocarray function not added to glibc?

Paul Eggert eggert@cs.ucla.edu
Sat Apr 8 23:10:00 GMT 2017


Dennis Wölfing wrote:
> the INT_MULTIPLY_OVERFLOW implementation uses compiler
> builtins only with GCC 7 or higher because it uses
> __builtin_mul_overflow_p.

Ah, you're right, I'd forgotten that because INT_MULTIPLY_OVERFLOW is also 
intended for use in constant expressions, it cannot use __builtin_mul_overflow.

> So I guess it's better to simply use
> __builtin_mul_overflow when __GNUC__ >= 5, and use the current
> implementation otherwise.

That would work, yes. Using INT_MULTIPLY_OVERFLOW instead of the current 
implementation would perhaps be better, if "better" is understood to mean 
simpler and/or less runtime code.

One other thing. Lots of C programs break if they allocate objects containing 
more than PTRDIFF_MAX bytes, since pointer subtraction stops working. Shouldn't 
realloc_array prevent this problem too? Something like this:

   static inline bool
   check_mul_overflow (size_t a, size_t b, size_t *result)
   {
   #if __GNUC_PREREQ (5, 0)
     bool v = __builtin_mul_overflow (a, b, result);
   #else
     *result = a * b;
     bool v = INT_MULTIPLY_OVERFLOW (a, b);
   #endif
     return v | PTRDIFF_MAX < *result;
   }

Of course a similar check should be added to malloc etc., but one step at a time.



More information about the Libc-alpha mailing list