Path: utzoo!attcan!uunet!husc6!mit-eddie!killer!chasm From: chasm@killer.DALLAS.TX.US (Charles Marslett) Newsgroups: comp.lang.c Subject: Re: correct code for pointer subtraction Summary: On the Atari, Mark Williams C gets it right Message-ID: <6704@killer.DALLAS.TX.US> Date: 7 Jan 89 18:19:02 GMT References: <597@mks.UUCP> <8377@bloom-beacon.MIT.EDU> <8455@sequent.UUCP> <2254@iscuva.ISCS.COM> Sender: 0000-Admin(0000) Organization: The Unix(R) Connection, Dallas, Texas Lines: 31 In article <2254@iscuva.ISCS.COM>, carlp@iscuva.ISCS.COM (Carl Paukstis) writes: > In article <22905@watmath.waterloo.edu> rwwetmore@grand.waterloo.edu (Ross Wetmore) writes: > I'm not sure which side of this I really want to argue :-) I have been on one side for a long time, but I've got to agree with this comment -- can't we go on to something else (how about Windows debuggers ... no, forget that!)? > ... What DOES happen in other 16-bit-int environments? > Would somebody care to run Eric's example and let me know the outcome? I'm > tempted to agree with Eric that a compiler which doesn't get the END RESULT > of the pointer arithmetic right is broken. At least Microsoft provides a > way to get the correct result, albeit with some "unusual" coding - what > does it take to get the right result in another 16-bit-int environment? The other environments I have used with 16-bit integers and 32-bit pointers all converted the intermediate result to long (so got the right result) or paid attention to the overflow and carry results of the 16-bit arithmetic (so they also got the right answer). > -- > Carl Paukstis +1 509 927 5600 x5321 |"The right to be heard does not > | automatically include the right > UUCP: carlp@iscuvc.ISCS.COM | to be taken seriously." > ...uunet!iscuva!carlp | - H. H. Humphrey =========================================================================== Charles Marslett STB Systems, Inc. <== Apply all standard disclaimers Wordmark Systems <== No disclaimers required -- that's just me chasm@killer.dallas.tx.us