Xref: utzoo comp.sys.ibm.pc:22117 comp.sys.intel:594
Path: utzoo!utgpu!watmath!mks!egisin
From: egisin@mks.UUCP (Eric Gisin)
Newsgroups: comp.sys.ibm.pc,comp.sys.intel
Subject: Re: correct code for pointer subtraction
Summary: wrong
Message-ID: <599@mks.UUCP>
Date: 12 Dec 88 23:07:19 GMT
References: <597@mks.UUCP> <8377@bloom-beacon.MIT.EDU>
Organization: Mortice Kern Systems, Waterloo, Ont.
Lines: 33

In article <8377@bloom-beacon.MIT.EDU>, adtaiwo@athena.mit.edu (Ademola Taiwo) writes:
> Hi,
> 	You should read your reference manual, (Turbo-C) specifically says
> that there are no denormalizations done in all memory models except HUGE, so
> you may want to use the Huge model and you are guaranteed 32-bit computations
> on your pointers, including proper denormals.

You don't know what you are talking about.
My example deals with pointers into an object of size 32K to 64K,
which near * and far * are claimed to work with.
Huge * is for objects larger than 64K.

My example program may be misleading because it declares diff() as long,
I really only expect an int.  An int is sufficient unless you are
comparing char *'s, but even then if you cast the difference to size_t
you get the correct value when p > q.
Even that should be unecessary, I thought ANSI added the ptrdiff_t
type specifically for 8086 brain-damage. It only takes "sbb dx,dx"
to widen the difference of two char *'s to the correct long value,
and that can be optimized away when a long value is not required.

> 	I think the compilers are right in generating 16bit code for all other
> memory models, since you have been warned about the trade-off of speed/space
> that you are making by chosing any other model but huge.
What? My fix doesn't cost anything, it changes one instruction.
If the compiler optimizes the divide into an arithmetic shift,
then you do have to add one instruction.

> 	On thesame note, pointer comparisons are not guaranteed to be correct
> in any model but huge. So if you want to fool arund with very big arrays, turn
> on the HUGE flag.
They are guaranteed when the operands point to components of the same object,
as was the case in my example.