Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!rutgers!princeton!udel!burdvax!sdcrdcf!ism780c!news
From: news@ism780c.UUCP (News system)
Newsgroups: comp.lang.c
Subject: Re: C machine
Message-ID: <8817@ism780c.UUCP>
Date: 1 Feb 88 22:39:31 GMT
References: <461@auvax.UUCP> <28700025@ccvaxa> <7159@brl-smoke.ARPA> <8728@ism780c.UUCP> <7199@brl-smoke.ARPA>
Reply-To: marv@ism780.UUCP (Marvin Rubenstein)
Organization: Interactive Systems Corp., Santa Monica CA
Lines: 23

In article <7199@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <8728@ism780c.UUCP> marv@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