Re: Plauger, size_t and ptrdiff_t

"Keith Thompson" <kst-u@xxxxxxx> wrote in message
news:ln1wy2e71y.fsf@xxxxxxxxxxxxxxxxxx

"robertwessel2@xxxxxxxxx" <robertwessel2@xxxxxxxxx> writes:
In another thread, a poster mentioned the Posix ssize_t definition
(signed version of size_t). My initial reaction was to wonder what the
point of the Posix definition was when ptrdiff_t was already defined as
such.

I got the idea that ptrdiff_t had to be the same size as size_t from
Plauger's "The Standard C Library," where he states "... It is always
the signed type that has the same number of bits as the4 unsigned type
chosen for size_t..." This language would not rule out one being int
and the other long so long as sizeof(int)==sizeof(long) for the
implementation.

Now I can't see anywhere in the standard that would require that, at
least not directly, and it seems that a size_t of unsigned int and a
prtdiff_t of long (where int and long are different sizes) would be
possible. C99 defines SIZE_MAX as being at least 65535, and
PTRDIFF_MIN/MAX as being at least -/+65535.

So do size_t and ptrdiff_t have to be the same size (or base type) or
not?

There's no requirement in the standard for size_t and ptrdiff_t to be
the same size, but I don't know of any implementation where they
differ.

ptrdiff_t is "the signed integer type of the result of subtracting two
pointers"; size_t is "the unsigned integer type of the result of the
sizeof operator".

Suppose a system only supports objects up to 65535 bytes. The sizeof
operator can only yield values from 0 to 65535, so 16 bits are
sufficient, but pointer subtraction for pointers to elements of an
array of 65535 bytes could yield values from -65535 to +65535, so
ptrdiff_t would have to be at least 17 bits.

Yes, but. X3J11 was painfully aware of this problem, which is why
we explicitly decided to allow some pointer differences to be
unrepresentable as a ptrdiff_t. I said what I said because that
was the reality at the time and it was certainly the intent of the
committee. Whether it got captured well in words...

BTW, even when you do get a ptrdiff_t overflow, on a (very common)
twos-complement machine with quiet wraparound on overflow there are
remarkably few cases where it matters.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


.

Relevant Pages

  • Re: [Lit.] Buffer overruns
    ... to retrieve from the stack. ... itself, "aha, I need to collect an int from the stack, so that'll ... The C Standard says, in 7.1.4: ... value outside the domain of the function, or a pointer outside ...
    (sci.crypt)
  • Re: CAN WE TYPE CAST AN INTEGER AS (VOID *)X..(Like can I return a value (void *)x)
    ... >> now suppose I have declared an integer value inside a function as int ... > there is no guarantee that an int might fit into a pointer. ... Standard knows nothing about stacks and similar real world concepts). ... Vladimir ...
    (comp.lang.c)
  • Re: Static _Bool initialization
    ... the standard rules out an overflow on the ... trap representations or hardware signals). ... Since the standard doesn't say that pointer addition ...
    (comp.std.c)
  • Re: which is the better way to declare dynamic single dimension array inside struct
    ... Pointer addition beyond the end of the array is undefined. ... > unsigned int flags; ... Standard, it is, surprise, surprise, _undefined_. ...
    (comp.lang.c)
  • Re: Static _Bool initialization
    ... Or rather, the standard rules out an overflow on the address calculation, and I don't see how 'non-null-address + x' could equal null for any positive x without overflow. ... Regardless of whether the standard otherwise rules out representing a one-past-the-end pointer of a particular array with a pointer that compares equal to a null pointer, the provision against overflow does not forbid such a pointer being the result of pointer arithmetic. ...
    (comp.std.c)