Xref: utzoo comp.lang.c:6314 comp.sys.m68k:660
Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!ulysses!allegra!mit-eddie!husc6!cmcl2!brl-adm!umd5!umbc3!alex
From: alex@umbc3.UUCP
Newsgroups: comp.lang.c,comp.sys.m68k
Subject: Re: C machine
Message-ID: <712@umbc3.UMD.EDU>
Date: 16 Jan 88 22:31:02 GMT
References: <461@auvax.UUCP> <9961@mimsy.UUCP> <166@teletron.UUCP> <6936@brl-smoke.ARPA> <147@ateng.UUCP> <39aca826.7f32@apollo.uucp> <7092@brl-smoke.ARPA> <708@umbc3.UMD.EDU> <7109@brl-smoke.ARPA>
Reply-To: alex@umbc3.UMD.EDU (Alex S. Crain)
Organization: University of Maryland, Baltimore County
Lines: 33
Posted: Sat Jan 16 17:31:02 1988

In article <7109@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>In article <708@umbc3.UMD.EDU> alex@umbc3.UMD.EDU (Alex S. Crain) writes:
>>Fix? How pray tell would you fix it? make it machine dependent? or just
>>arbitrary? 
>
>It should be obvious what to do if you think about it.
>
>First, only pointers into the same object can meaningfully be subtracted.
>Second, the result of the subtraction necessarily has implementation-
>defined signed integral type; there is a typedef ptrdiff_t in <stddef.h>.


	Hmm..

	I don't really understand the answer, I think you said "impementation
dependant". If so, how is that a fix? when I'm calculating offsets in a lisp
implementation, and I decide that the fastest way is to use the actual 
addresses and reletively reference functions, and i say 

	funcall (ptr1 - ptr2); /* ptr1 - ptr2 > 64k */

what happens? or do I just check stddef.h for the answer?

	I would prefer 32bit (or rather, the largest default integer available
including pointers) ints, because conversion to short int is absolutely 
painless (mov.l becomes mov.w) while conversion the other way can be a rather
serious problem.


-- 
					:alex.

alex@umbc3.umd.edu