Does in glibc, the sizeof(ssize_t) always equals to sizeof(size_t)

[Paul Eggert]

On 2026-05-23 06:12, Yonggang Luo wrote:

>> Yes, that's what I meant. They all had ssize_t narrower than size_t.
>> This was for backward compatibility, e.g., their 'read' syscall always
>> returned a 32-bit signed int even though size_t was 64 bits. In some of
> 
> oh the syscall(NOT POSIX) is returning a 32-bit signed int, we can use a
> 64-bit signed int to store it without loss.
> So for these old systems, restrict sizeof(ssize_t) == sizeof(size_t) won't
> hurt them.

Obviously those systems could have been designed with sizeof(ssize_t) == 
sizeof(size_t) if they had been designed from scratch. But that would 
have broken their already existing ABIs. The people who developed those 
systems weren't idiots: they were merely constrained by backward 
compatibility.

>> Perhaps this could happen in the future with 64-bit ssize_t and 128-bit
>> size_t, right?
My point here is, suppose a hypothetical far-future system has 128-bit 
size_t. Almost surely it will have both traditional (64-bit) mode and 
new 128-bit mode with a kernel supporting both. Will POSIX insist that 
the 128-bit mode be clean and designed from scratch with 128-bit 
ssize_t, or will it allow the same sort of hybrid that some platforms 
did in the 16->32 and 32->64 transitions?