Date: Tue, 01 Jul 2025 19:32:00 -0700
On Tuesday, 1 July 2025 16:59:51 Pacific Daylight Time Yexuan Xiao via Std-
Proposals wrote:
> This is also why size_t is so important—it is designed to be as large as
> possible to handle as much data as needed.
That's not what size_t is for. It is the unsigned type that can represent all
object sizes, therefore it is what the sizeof operator and expressions return.
But it is not necessarily the largest unsigned integer nor does it need to be
"as much data" in all circumstances. For example, if a given platform limited
the size of all objects to 16 bits, then combining multiple such objects would
yield a size bigger than 16 bits can represent.
This platform existed: 16-bit DOS in all memory models except the huge one.
32-bit x86 could do the same with 32 bit object sizes but addressing more than
4 GB of memory, but fortunately this was never deployed (AFAIK) for
applications. 32-bit kernels did need to deal with 36-bit memory addresses.
Proposals wrote:
> This is also why size_t is so important—it is designed to be as large as
> possible to handle as much data as needed.
That's not what size_t is for. It is the unsigned type that can represent all
object sizes, therefore it is what the sizeof operator and expressions return.
But it is not necessarily the largest unsigned integer nor does it need to be
"as much data" in all circumstances. For example, if a given platform limited
the size of all objects to 16 bits, then combining multiple such objects would
yield a size bigger than 16 bits can represent.
This platform existed: 16-bit DOS in all memory models except the huge one.
32-bit x86 could do the same with 32 bit object sizes but addressing more than
4 GB of memory, but fortunately this was never deployed (AFAIK) for
applications. 32-bit kernels did need to deal with 36-bit memory addresses.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Platform & System Engineering
Received on 2025-07-02 02:32:04