Plauger, size_t and ptrdiff_t

[robertwessel2@yahoo.com]

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)==si zeof(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?

[Michael Mair]

Re: Plauger, size_t and ptrdiff_t

robertwessel2@y ahoo.com schrieb:[color=blue]
> 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)==si zeof(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?[/color]

They don't. For most implementations , the stated connection
will hold.
size_t, ssize_t and ptrdiff_t are typedefed for their respective
_roles_ as well as for abstraction.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Keith Thompson]

Re: Plauger, size_t and ptrdiff_t

"robertwessel2@ yahoo.com" <robertwessel2@ yahoo.com> writes:[color=blue]
> 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)==si zeof(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?[/color]

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.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[P.J. Plauger]

Re: Plauger, size_t and ptrdiff_t

"Keith Thompson" <kst-u@mib.org> wrote in message
news:ln1wy2e71y .fsf@nuthaus.mi b.org...
[color=blue]
> "robertwessel2@ yahoo.com" <robertwessel2@ yahoo.com> writes:[color=green]
>> 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)==si zeof(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?[/color]
>
> 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.[/color]

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

[Jordan Abel]

Re: Plauger, size_t and ptrdiff_t

On 2006-02-17, Keith Thompson <kst-u@mib.org> wrote:[color=blue]
> "robertwessel2@ yahoo.com" <robertwessel2@ yahoo.com> writes:[color=green]
>> 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)==si zeof(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?[/color]
>
> 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.[/color]

How about an implementation where size_t is unsigned int and ptrdiff_t
is long? If all base types have only the minimum ranges, you can fit
size_t in an unsigned int but can't fit ptrdiff_t in an int.

[Keith Thompson]

Re: Plauger, size_t and ptrdiff_t

"P.J. Plauger" <pjp@dinkumware .com> writes:[color=blue]
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:ln1wy2e71y .fsf@nuthaus.mi b.org...[/color]
[...][color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]

Ok, I see that the standard explicitly allows the result of ptr1-ptr2
not to fit in a ptrdiff_t (it's undefined behavior if it doesn't).
But I don't see anything that requires, or even encourages, size_t and
ptrdiff_t to be the same size.

If the maximum object size is, say, 65535 bytes, the standard
*permits* size_t and ptrdiff_t to be 16 bits, but is there any reason
(as far as the standard is concerned) not to make size_t 16 bits and
ptrdiff_t 32 bits?

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Re: Plauger, size_t and ptrdiff_t

Jordan Abel <random832@gmai l.com> writes:[color=blue]
> On 2006-02-17, Keith Thompson <kst-u@mib.org> wrote:[/color]
[...][color=blue][color=green]
>> 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.[/color]
>
> How about an implementation where size_t is unsigned int and ptrdiff_t
> is long? If all base types have only the minimum ranges, you can fit
> size_t in an unsigned int but can't fit ptrdiff_t in an int.[/color]

Then that would be an implementation I don't know of. (It's legal as
far as I know.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[P.J. Plauger]

Re: Plauger, size_t and ptrdiff_t

"Keith Thompson" <kst-u@mib.org> wrote in message
news:ln3bihd4s8 .fsf@nuthaus.mi b.org...
[color=blue]
> "P.J. Plauger" <pjp@dinkumware .com> writes:[color=green]
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:ln1wy2e71y .fsf@nuthaus.mi b.org...[/color]
> [...][color=green][color=darkred]
>>> 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.[/color]
>>
>> 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.[/color]
>
> Ok, I see that the standard explicitly allows the result of ptr1-ptr2
> not to fit in a ptrdiff_t (it's undefined behavior if it doesn't).
> But I don't see anything that requires, or even encourages, size_t and
> ptrdiff_t to be the same size.
>
> If the maximum object size is, say, 65535 bytes, the standard
> *permits* size_t and ptrdiff_t to be 16 bits, but is there any reason
> (as far as the standard is concerned) not to make size_t 16 bits and
> ptrdiff_t 32 bits?[/color]

There's just Nixon's rule -- you could do it, but it would be wrong.

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[Keith Thompson]

Re: Plauger, size_t and ptrdiff_t

"P.J. Plauger" <pjp@dinkumware .com> writes:[color=blue]
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:ln3bihd4s8 .fsf@nuthaus.mi b.org...[/color]
[...][color=blue][color=green]
>> Ok, I see that the standard explicitly allows the result of ptr1-ptr2
>> not to fit in a ptrdiff_t (it's undefined behavior if it doesn't).
>> But I don't see anything that requires, or even encourages, size_t and
>> ptrdiff_t to be the same size.
>>
>> If the maximum object size is, say, 65535 bytes, the standard
>> *permits* size_t and ptrdiff_t to be 16 bits, but is there any reason
>> (as far as the standard is concerned) not to make size_t 16 bits and
>> ptrdiff_t 32 bits?[/color]
>
> There's just Nixon's rule -- you could do it, but it would be wrong.[/color]

And why exactly would it be wrong? I see nothing in the standard that
even vaguely implies that size_t and ptrdiff_t should be the same
size, and there are realistic circumstances (see above) in which it
would make perfectly good sense, IMHO, for ptrdiff_t to be larger than
size_t. The standard's wording caters to implementations that choose
to make them the same size, but that's very different from encouraging
them to be the same size.

Your opinion does carry significant weight, but I'd be very interested
in knowing the reasoning behind it. In the meantime, I can't think of
any reason to write code that could break on systems where ptrdiff_t
is bigger than size_t.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[P.J. Plauger]

Re: Plauger, size_t and ptrdiff_t

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnbqx48f1h .fsf@nuthaus.mi b.org...
[color=blue]
> "P.J. Plauger" <pjp@dinkumware .com> writes:[color=green]
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:ln3bihd4s8 .fsf@nuthaus.mi b.org...[/color]
> [...][color=green][color=darkred]
>>> Ok, I see that the standard explicitly allows the result of ptr1-ptr2
>>> not to fit in a ptrdiff_t (it's undefined behavior if it doesn't).
>>> But I don't see anything that requires, or even encourages, size_t and
>>> ptrdiff_t to be the same size.
>>>
>>> If the maximum object size is, say, 65535 bytes, the standard
>>> *permits* size_t and ptrdiff_t to be 16 bits, but is there any reason
>>> (as far as the standard is concerned) not to make size_t 16 bits and
>>> ptrdiff_t 32 bits?[/color]
>>
>> There's just Nixon's rule -- you could do it, but it would be wrong.[/color]
>
> And why exactly would it be wrong?[/color]

Because there's next to nothing to be gained by it, and some people
would be surprised that ptrdiff_t is unnecessarily large. (I won't
even mention a third of a century of past practice.)
[color=blue]
> I see nothing in the standard that
> even vaguely implies that size_t and ptrdiff_t should be the same
> size,[/color]

There's nothing in the C Standard that prohibits 93 bit chars, either.
[color=blue]
> and there are realistic circumstances (see above) in which it
> would make perfectly good sense, IMHO, for ptrdiff_t to be larger than
> size_t.[/color]

Maybe by one bit, but as I said before even there it matters way less
than you might think.
[color=blue]
> The standard's wording caters to implementations that choose
> to make them the same size, but that's very different from encouraging
> them to be the same size.[/color]

Right. The C Standard is not intended to rule out silly implementations .
[color=blue]
> Your opinion does carry significant weight, but I'd be very interested
> in knowing the reasoning behind it. In the meantime, I can't think of
> any reason to write code that could break on systems where ptrdiff_t
> is bigger than size_t.[/color]

Nor do I encourage that either.

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[tmp123]

Re: Plauger, size_t and ptrdiff_t

P.J. Plauger wrote:[color=blue]
> "Keith Thompson" <kst-u@mib.org> wrote in message
>[color=green]
> > "P.J. Plauger" <pjp@dinkumware .com> writes:[color=darkred]
> >> "Keith Thompson" <kst-u@mib.org> wrote in message[/color]
> > [...][color=darkred]
> >>> Ok, I see that the standard explicitly allows the result of ptr1-ptr2
> >>> not to fit in a ptrdiff_t (it's undefined behavior if it doesn't).
> >>> But I don't see anything that requires, or even encourages, size_t and
> >>> ptrdiff_t to be the same size.
> >>>
> >>> If the maximum object size is, say, 65535 bytes, the standard
> >>> *permits* size_t and ptrdiff_t to be 16 bits, but is there any reason
> >>> (as far as the standard is concerned) not to make size_t 16 bits and
> >>> ptrdiff_t 32 bits?
> >>
> >> There's just Nixon's rule -- you could do it, but it would be wrong.[/color]
> >
> > And why exactly would it be wrong?[/color]
>
> Because there's next to nothing to be gained by it, and some people
> would be surprised that ptrdiff_t is unnecessarily large. (I won't
> even mention a third of a century of past practice.)
>[/color]

....

Sorry, I do not understand something:

Result of calloc is an array that, according to calloc parameters, can
be up to size_t**2 bytes. ptrdiff_t must be long enough for pointer
differences in its elements. Thus, ptrdiff_t must be greater than
size_t (or both must have the maximum system value)

In other words: it is easy think about a system that doesn't allows big
structure definitions (by example, a maximum of one "memory page" of
4096 bytes --> size_t=4096 ), but this system can accept big dynamic
arrays (ptrdiff_t --> +/-0x7FFFFFFF).

I suposse there are some more related rules I do not know.

Kind regards.

[P.J. Plauger]

Re: Plauger, size_t and ptrdiff_t

"tmp123" <tmp123@menta.n et> wrote in message
news:1140344656 .778133.245580@ g47g2000cwa.goo glegroups.com.. .
[color=blue]
> P.J. Plauger wrote:[color=green]
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>[color=darkred]
>> > "P.J. Plauger" <pjp@dinkumware .com> writes:
>> >> "Keith Thompson" <kst-u@mib.org> wrote in message
>> > [...]
>> >>> Ok, I see that the standard explicitly allows the result of ptr1-ptr2
>> >>> not to fit in a ptrdiff_t (it's undefined behavior if it doesn't).
>> >>> But I don't see anything that requires, or even encourages, size_t
>> >>> and
>> >>> ptrdiff_t to be the same size.
>> >>>
>> >>> If the maximum object size is, say, 65535 bytes, the standard
>> >>> *permits* size_t and ptrdiff_t to be 16 bits, but is there any reason
>> >>> (as far as the standard is concerned) not to make size_t 16 bits and
>> >>> ptrdiff_t 32 bits?
>> >>
>> >> There's just Nixon's rule -- you could do it, but it would be wrong.
>> >
>> > And why exactly would it be wrong?[/color]
>>
>> Because there's next to nothing to be gained by it, and some people
>> would be surprised that ptrdiff_t is unnecessarily large. (I won't
>> even mention a third of a century of past practice.)
>>[/color]
>
> ...
>
> Sorry, I do not understand something:
>
> Result of calloc is an array that, according to calloc parameters, can
> be up to size_t**2 bytes.[/color]

The calloc parameters might permit you to request that, but the system
can't deliver it. size_t by definition is an unsigned integer type
big enough to represent the count of bytes in the largest object you
can declare or allocate.
[color=blue]
> ptrdiff_t must be long enough for pointer
> differences in its elements.[/color]

Actually, no. The difference between two pointers is permitted to
overflow when represented as an object of type ptrdiff_t.
[color=blue]
> Thus, ptrdiff_t must be greater than
> size_t (or both must have the maximum system value)[/color]

Neother is true.
[color=blue]
> In other words: it is easy think about a system that doesn't allows big
> structure definitions (by example, a maximum of one "memory page" of
> 4096 bytes --> size_t=4096 ), but this system can accept big dynamic
> arrays (ptrdiff_t --> +/-0x7FFFFFFF).
>
> I suposse there are some more related rules I do not know.[/color]

Yes. See above.

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[Keith Thompson]

Re: Plauger, size_t and ptrdiff_t

"P.J. Plauger" <pjp@dinkumware .com> writes:[color=blue]
> "tmp123" <tmp123@menta.n et> wrote in message
> news:1140344656 .778133.245580@ g47g2000cwa.goo glegroups.com.. .[/color]
[...][color=blue][color=green]
>> ptrdiff_t must be long enough for pointer
>> differences in its elements.[/color]
>
> Actually, no. The difference between two pointers is permitted to
> overflow when represented as an object of type ptrdiff_t.[/color]

Agreed, but you seem to be arguing that it's *better* for an
implementation to allow pointer subtraction to overflow than to make
ptrdiff_t bigger than size_t. I respectfully disagree.

Note that this would be necessary only when the maximum object size is
greater than SIZE_MAX/2 *and* size_t is the largest available integer
type. Since C99 requires support for 64-bit integers, that's unlikely
to happen for a long time. But a system with a 32-bit size_t that
allows objects larger than 2 gigabytes (but not larger than 4
gigabytes) might reasonably have a 64-bit ptrdiff_t. (33 bits would
suffice, but I'm assuming hardware support for 32 and 64 bits.) (It
might also reasonably expand its size_t to 64 bits.)

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Jordan Abel]

Re: Plauger, size_t and ptrdiff_t

On 2006-02-19, tmp123 <tmp123@menta.n et> wrote:[color=blue]
> P.J. Plauger wrote:[color=green]
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>[color=darkred]
>> > "P.J. Plauger" <pjp@dinkumware .com> writes:
>> >> "Keith Thompson" <kst-u@mib.org> wrote in message
>> > [...]
>> >>> Ok, I see that the standard explicitly allows the result of ptr1-ptr2
>> >>> not to fit in a ptrdiff_t (it's undefined behavior if it doesn't).
>> >>> But I don't see anything that requires, or even encourages, size_t and
>> >>> ptrdiff_t to be the same size.
>> >>>
>> >>> If the maximum object size is, say, 65535 bytes, the standard
>> >>> *permits* size_t and ptrdiff_t to be 16 bits, but is there any reason
>> >>> (as far as the standard is concerned) not to make size_t 16 bits and
>> >>> ptrdiff_t 32 bits?
>> >>
>> >> There's just Nixon's rule -- you could do it, but it would be wrong.
>> >
>> > And why exactly would it be wrong?[/color]
>>
>> Because there's next to nothing to be gained by it, and some people
>> would be surprised that ptrdiff_t is unnecessarily large. (I won't
>> even mention a third of a century of past practice.)
>>[/color]
>
> ...
>
> Sorry, I do not understand something:
>
> Result of calloc is an array that, according to calloc parameters, can
> be up to size_t**2 bytes. ptrdiff_t must be long enough for pointer
> differences in its elements. Thus, ptrdiff_t must be greater than
> size_t (or both must have the maximum system value)[/color]

The system can [and many do. mine does.] fail all calls to calloc that
result in a size that won't fit in size_t.

[Jordan Abel]

Re: Plauger, size_t and ptrdiff_t

On 2006-02-19, Keith Thompson <kst-u@mib.org> wrote:[color=blue]
> "P.J. Plauger" <pjp@dinkumware .com> writes:[color=green]
>> "tmp123" <tmp123@menta.n et> wrote in message
>> news:1140344656 .778133.245580@ g47g2000cwa.goo glegroups.com.. .[/color]
> [...][color=green][color=darkred]
>>> ptrdiff_t must be long enough for pointer
>>> differences in its elements.[/color]
>>
>> Actually, no. The difference between two pointers is permitted to
>> overflow when represented as an object of type ptrdiff_t.[/color]
>
> Agreed, but you seem to be arguing that it's *better* for an
> implementation to allow pointer subtraction to overflow than to make
> ptrdiff_t bigger than size_t. I respectfully disagree.[/color]

But a system could implement a "magic overflow" - i.e. the size of
size_t, char *, and ptrdiff_t are all the same and overflow acts like
typical twos-complement systems.

Then the [char *] pointer difference 0x01-0xFFF3 is 14 [not -65522], and
adding 14 to the pointer 0xFFF3 results in 0x01.
[color=blue]
> Note that this would be necessary only when the maximum object size is
> greater than SIZE_MAX/2 *and* size_t is the largest available integer
> type. Since C99 requires support for 64-bit integers, that's unlikely
> to happen for a long time. But a system with a 32-bit size_t that
> allows objects larger than 2 gigabytes (but not larger than 4
> gigabytes) might reasonably have a 64-bit ptrdiff_t. (33 bits would
> suffice, but I'm assuming hardware support for 32 and 64 bits.) (It
> might also reasonably expand its size_t to 64 bits.)[/color]