Path: utzoo!attcan!uunet!husc6!rutgers!att!mtuxo!mtgzz!drutx!clive
From: clive@drutx.ATT.COM (Clive Steward)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Pointer Subtraction in THINK C 3.0 (vs several earlier)
Message-ID: <8413@drutx.ATT.COM>
Date: 7 Aug 88 19:55:37 GMT
References: <63033@sun.uucp>
Organization: resident visitor
Lines: 30

From article <63033@sun.uucp>, by swilson%thetone@Sun.COM (Scott Wilson):
> 
> It looks as though THINK C 3.0 is using long as the resulting type for
> pointer subtraction.

(does this seem wrong?)

[summarized]
> According to K&R: (subtracted pointers -> int) (pdp11 ptr size = int, right?)
> 	       ANSI: subtracted pointers -> mfgr defined, hopefully sensible

Well, maybe they got complaints, as I might have given last night, trying
to figure out why a program blew up, compiled with LSC2.13, when it worked 
fine on earlier versions.

I had:  txtmax = inbuf + (48 * 1024 - 1);	/* inbuf is malloc'd char[] */

    this produced txtmax (buffer limit) _negative_ to inbuf.  Apparently 
    2.13 followed the book rules again, where 3.0 deviates sensibly.

what worked, by the way: txtmax = inbuf + (48L * 1024L - 1L);

Personally, I think this is all a little too tricky, and am glad
that they've gone back to results of subtractions being in the
type of the arguments.  Seems it should never have been otherwise,
and that the K&R thing is just a slipup -- clearly two pointers
can have a bigger difference than an int can hold, depending on sizes.


Clive Steward