Why was the reallocarray function not added to glibc?

[Dennis Wölfing]

On 09.04.2017 01:10, Paul Eggert wrote:
> 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;
>   }

I don't think that the PTRDIFF_MAX check belongs into
check_mul_overflow. All memory allocation functions should perform that
check and since reallocarray calls realloc the check would then be
preformed twice.

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

I think any PTRDIFF_MAX checks belong into a different patch.