correct code for pointer subtraction

[Carl Paukstis]

In article <22905 at watmath.waterloo.edu> rwwetmore at grand.waterloo.edu (Ross Wetmore) writes:
>In article <2245 at iscuva.ISCS.COM> carlp at iscuva (Carl Paukstis) writes:
>>Eric Gisin at Mortice Kern Systems writes:
>>>How come I can't find a compiler that generates correct
>>>code for pointer subtraction in C on 8086s?
>>>Neither Turbo, Microsoft, or Watcom do it right.
>>>
>>>All of the compilers I tried computed a 16 bit difference,
>>>then sign extended it before dividing.
>>>This does not work if the pointers differ by more than 32K.
                                                          ^^^ BYTES!
>>
>>(NOTE CRITICAL POINT FOR ERIC'S COMPLAINT:  the difference between s and
>>s+10000 is 60,000 bytes - easily less that the 64K segment limit)

>  The 64K segment limit has little to do with it. The 16 bit architecture
>ie 16 bit _int_ is the determining factor.

I'm not sure which side of this I really want to argue :-)

In Eric's original code, the difference was between two pointers to
structures, each structure six bytes long.  The pointer difference, if
properly computed, comes out 10,000 - which I would think is fairly easy to
represent in a 16-bit int.  The difference in BYTES (a necessary
intermediate step in the generated code) doesn't fit in a 16-bit signed
int, which Microsoft (sort of) recognizes with their comment in the manual
from which I was quoting about casting to long.  Apparently they do "the
right thing" when the pointers are "huge" - they do a 32-bit (20-bit?) 
difference using the segment registers.  

This is what prompted my (admittedly somewhat muddled) remark about 
"CRITICAL POINT".  They provide a way to get the right answer, but only
when you use "huge" pointers, which include the segment information.

>  ... but forgot when you let your prejudices take control.

OK, I'm not happy about segmented address space, at least the Intel
version.  I do find the MS-DOS software base useful, and I even kind of
enjoy the arcana of 80?86 PC's - call me a masochist.

>                                 However, is the point not clear ... ?

Which point was 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?

-- 
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