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