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