https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119693
--- Comment #8 from Jann Horn <jannh at google dot com> ---
(In reply to Harald van Dijk from comment #7)
> I think implementations have two valid ways of dealing with this: either
> malloc must fail to allocate such a large object, or standard library
> functions must handle such a large object. This could be solved in a 100%
> unambiguously valid way on the glibc side by changing malloc to reject such
> sizes, but on an implementation where malloc supports such sizes, I think
> all of the standard library needs to be prepared to handle that.
To be clear, I believe glibc malloc rejects object sizes over PTRDIFF_MAX; I
think at least under glibc, you'd have to use a mechanism other than malloc()
to obtain bigger objects:
```
/* Check if REQ overflows when padded and aligned and if the resulting
value is less than PTRDIFF_T. Returns the requested size or
MINSIZE in case the value is less than MINSIZE, or 0 if any of the
previous checks fail. */
static inline size_t
checked_request2size (size_t req) __nonnull (1)
{
if (__glibc_unlikely (req > PTRDIFF_MAX))
return 0;
[...]
}
[...]
static void *
_int_malloc (mstate av, size_t bytes)
{
[...]
/*
Convert request size to internal form by adding SIZE_SZ bytes
overhead plus possibly more to obtain necessary alignment and/or
to obtain a size of at least MINSIZE, the smallest allocatable
size. Also, checked_request2size returns false for request sizes
that are so large that they wrap around zero when padded and
aligned.
*/
nb = checked_request2size (bytes);
if (nb == 0)
{
__set_errno (ENOMEM);
return NULL;
}
```
