correct code for pointer subtraction

Charles Marslett chasm at killer.DALLAS.TX.US
Sun Jan 8 04:19:02 AEST 1989


In article <2254 at iscuva.ISCS.COM>, carlp at iscuva.ISCS.COM (Carl Paukstis) writes:
> In article <22905 at watmath.waterloo.edu> rwwetmore at 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 at 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 at killer.dallas.tx.us



More information about the Comp.lang.c mailing list