Date: Wed, 2 Jul 2025 07:40:23 +0000
Although I have never programmed on such platforms, I know the story. I don’t consider it an ideal platform—it became obsolete along with early C and early C++, even though it was successful. The 80386 completely replaced it. Programming on such a platform seems extremely difficult, which is perhaps why it is no longer in use. It was merely a compromise of a specific developmental stage, and I’m glad I’m now far from that era.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]>
Sent: Wednesday, July 2, 2025 10:32
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Thiago Macieira <thiago_at_[hidden]>
Subject: Re: [std-proposals] Shorter fixed-width integer types
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.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]>
Sent: Wednesday, July 2, 2025 10:32
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Thiago Macieira <thiago_at_[hidden]>
Subject: Re: [std-proposals] Shorter fixed-width integer types
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.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Platform & System Engineering -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fstd-proposals&data=05%7C02%7C%7C8c176ca6f519480953ed08ddb91158a1%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638870206347650376%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nqrig3oPbWUSdH1pS3YR8YXXWcK6UctoJflhasEdCE8%3D&reserved=0<https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
Received on 2025-07-02 07:40:28