wolpert@hpisla.HP.COM (David Wolpert) (01/21/88)
pablo@polygen.uucp (Pablo Halpern) writes:"
"or better yet
" typedef long ptrdiff_t;
" typedef unsigned size_t;
"
"The reason for the long ptrdiff_t definition is that the difference
"between two unsigned, 16-bit pointers can excede the -32768 - +32767
"range of a 16-bit two's compliment signed integer.
... but the 32-bit case is the same: the difference between two unsigned
32-bit pointers can exceed the range of a 32-bit 2's complement number.
Maybe ptrdiff_t wasn't intended to handle the case of more than half of
the machine's address space allocated to one object?
More seriously, _is_ there a way to handle this? Not that it'll ever
come up :-), but it looks as if I need to know the approximate expected
result of a pointer-subtraction to make the code foolproof (and check
for overflow myself).
_ _
/ \/ \ wolpert@hpisla.HP.COM David Wolpert
/_ __ HEWLETT \ / Measurement Systems Operation
/ / /_/ PACKARD \ / P O Box 301 - Loveland, CO 80539
/ \/ (303) 667-5000 x3533
======================================================================
"Be joyful always; pray continually; give thanks in all circumstances"gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/23/88)
In article <5360001@hpisla.HP.COM> wolpert@hpisla.HP.COM (David Wolpert) writes: >... but the 32-bit case is the same: the difference between two unsigned >32-bit pointers can exceed the range of a 32-bit 2's complement number. >Maybe ptrdiff_t wasn't intended to handle the case of more than half of >the machine's address space allocated to one object? Yes, on a 32-bit "long" machine, ptrdiff_t cannot represent the difference of pointers TO CHARS in an array having more than 2^31 chars. Pointers to things larger than chars have no such problem. We couldn't think of any clean way to fix this part of the pointer-diff problem, and decided it wasn't very important in practice. Who would actually have an application that needs to do this?