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

[Yonggang Luo]

On Sun, May 24, 2026 at 12:01 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> 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

The ssize_t is the signed version of size_t from its name, otherwise we can
name it with int or int32_t.


> have broken their already existing ABIs. The people who developed those
> systems weren't idiots: they were merely constrained by backward
> compatibility.

About backward compatibility, it can be achieved by macros. We can expose
both functions, one is int32_t that has compatibility with the old one.
And the other one is ssize_t.


>
> >> 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

If 128-bit size_t is raised, then 128-bit ssize_t makes sense.


> new 128-bit mode with a kernel supporting both. Will POSIX insist that
The kernel can always choose to use int across different sizeof(size_t) if
it satisfies the kernel's requirements.
The POSIX does not define how the kernel syscall is defined.

int => ssize_t is  signed-extending, so it's safe.

> 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?

Yeap, constraint sizeof(ssize_t) === sizeof(size_t) as its name is leading
to this result, I could say in 99% or more code
already assume this assertion. I think rare people know that rare OS have (
sizeof(ssize_t) !== sizeof(size_t)   )



--
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260524/7c174aa6/attachment-0001.htm>