C machine
News system
news at ism780c.UUCP
Tue Feb 2 08:39:31 AEST 1988
In article <7199 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <8728 at ism780c.UUCP> marv at ism780.UUCP (Marvin Rubenstein) writes:
>-The problem with a header file defining a type ptrdiff_t is that the the
>-defined type must be one of the types in the base C language. If an
>-implementation defines ptrdiff_t such that sizeof(ptrdiff_t) == sizeof(void*)
>-then p1-p2 may overflow.
>
>"As with any other arithmetic overflow, if the result does not fit in the
>space provided, the behavior is undefined."
>
>It is up to the implementation to choose a reasonable size for ptrdiff_t.
The problem I (Marv Rubinstein) was trying to address is that soon (hopfully
before we discard C) there will be machines with 48 bit (or longer) pointers
and 32 bit arithmetic registers. On such a machine character arrays with
more than 2**31 elements will be reasonable. In order to be conformining
'longs' would have to be defined to contain more than 32 bits to hold
(reasonable) pointer differences, while other operations on longs would need
only 32 bits. That is why I think a more general solution would be to have
the type ptrdiff_t built into the language. Note I am not suggesting a
change in the language, I am only suggesting that the the proposed solution
is only marginally better than K&R's pointer difference is an int.
Marv Rubinstein
More information about the Comp.lang.c
mailing list