Re: [Bug-gnulib] proposed vasnprintf patches for address arithmetic and stack overflow

[Bruno Haible]

Paul Eggert wrote:
> > What I needed here was a signed type, of the same size as 'size_t'.
>
> I don't see why.  If you could assume a signed type that is wider than
> size_t, and can represent all signed_t values, then the code would be
> simpler and more reliable; there would be no need to check against
> arithmetic overflow.

But then I would have one more unknown to care about: the case when
sizeof (ptrdiff_t) > sizeof (size_t). This case is hard to test.
I've in fact already produced bugs in glibc code that occurred only
when 'int' is a 64-bit type, and of course when it showed up it was
hard to track down.

> > You cannot guarantee that ssize_t and ptrdiff_t have the same size.
>
> No.  However, as a practical matter I can say that ptrdiff_t is at
> least as wide as ssize_t.  There have been C implementations where
> ptrdiff_t was wider than size_t.  I know of no implementations where
> ssize_t was wider than size_t.  So, as a practical matter (i.e.,
> ignoring standards issues), it's safer to use ptrdiff_t to represent
> differences between pointers into the same array.

ptrdiff_t is better than ssize_t, if you want to represent _signed_
differences between pointers, But since there's the problem with
arrays > 2 GB, it's generally better to always work with _unsigned_
differences between pointers, and then 'size_t' is good enough.
We don't need 'u_ptrdiff_t'.

> I have heard of environments where ptrdiff_t was wider than size_t.  I
> don't recall their names offhand.  I believe they used 16-bit size_t
> and 32-bit ptrdiff_t

So the meaning of size_t is related to the size of a single memory
object, whereas ptrdiff_t is more related to the memory size as a whole.

Bruno