Hi Thiago,

On 2026-04-16T15:27:57-0700, Thiago Macieira via Std-Proposals wrote:
> On Thursday, 16 April 2026 02:00:53 Pacific Daylight Time Marcin Jaczewski via
> Std-Proposals wrote:
> > This means the standard should guarantee that we can't allocate more
> > than `MAX_INT` and I recall that C had something like this as
> > there was a macro that was "max allocation size".
> > With this most rollovers will not be a problem.
>
> malloc() cannot return a block bigger than PTRDIFF_MAX-1, because then the
> distance between one-past-end and the beginning would be negative. You may
> have seen the annoying warnings from GCC that you may be trying to allocate
> more than 2^63 bytes (even though you aren't).
>
> On some esoteric platform where ptrdiff_t is bigger than size_t, SIZE_MAX would
> be the limit. On almost everything, they have the same size, so PTRDIFF_MAX is
> the limit.
>
> That means there are exactly two containers in the Standard that could have
> more than PTRDIFF_MAX elements, on a common (albeit 32-bit these days)
> platform: std::deque<char> and std::bitset.
>
> > I read that a long time ago about this and possibly I confuse
> > something, but after googling I found this:
> > `RSIZE_MAX` but it's not linked directly to `malloc` more for safer C
> > string functions.
>
> Yeah, that's Annex K stuff. Forget it exists.

One could say it doesn't even exist at all. Only a few weird (one?
two?) implementations exist, and I'm not sure if any of them is
conforming.

I'm trying to remove it from the standard, but it ain't easy to convince
wg14 to remove something they added. :)


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>