[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnulib] proposed vasnprintf patches for address arithmetic and
Re: [Bug-gnulib] proposed vasnprintf patches for address arithmetic and stack overflow
Wed, 19 Nov 2003 17:48:51 +0100
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.
Re: [Bug-gnulib] proposed vasnprintf patches for address arithmetic and stack overflow, Bruno Haible, 2003/11/18