[PATCH 2/2] malloc: make malloc fail with requests larger than PTRDIFF_MAX

Paul Eggert eggert@cs.ucla.edu
Fri Dec 21 23:06:00 GMT 2018


The patch assumes that PTRDIFF_MAX is well under SIZE_MAX. A while ago Joseph 
wrote that m32c sometimes has ptrdiff_t wider than size_t 
<https://gcc.gnu.org/ml/gcc-patches/2011-07/msg00483.html> and if someone ever 
does a glibc port to such a platform this issue will come up in unlikely cases. 
Perhaps add something like the following to malloc/malloc.c, to make sure the 
problem is harder to ignore on such platforms?

/* malloc.c assumes that ptrdiff_t has no more bits than size_t.
    Although this assumption could be removed without hurting typical-case
    performance, doing this is low priority since the assumption holds
    on all current glibc platforms.  */
#include <verify.h>
verify (PTRDIFF_MAX <= SIZE_MAX / 2);


> +  if (__glibc_unlikely (bytes > PTRDIFF_MAX - padsize))
> +    {
> +      __set_errno (ENOMEM);
> +      return NULL;
> +    }

Why is the '- padsize' needed in these cases? All the relevant arithmetic is 
done using size_t, so overflow can't occur when PTRDIFF_MAX - padsize < bytes <= 
PTRDIFF_MAX, under the PTRDIFF_MAX <= SIZE_MAX / 2 assumption that the code is 
already making elsewhere.


> +  if (INT_MULTIPLY_WRAPV (n, elem_size, &bytes)
> +      || __glibc_unlikely (bytes > PTRDIFF_MAX - padsize))

This can be made a bit simpler by changing the type of this particular 'bytes' 
variable to ptrdiff_t and then by removing the "|| __glibc_unlikely (bytes > 
PTRDIFF_MAX - padsize)", since the "- padsize" isn't needed and the 
INT_MULTIPLY_WRAPV will check for exceeding PTRDIFF_MAX if 'bytes' is of type 
ptrdiff_t.



More information about the Libc-alpha mailing list