Xref: utzoo comp.sys.ibm.pc:22394 comp.sys.intel:612
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ukma!husc6!mit-eddie!killer!chasm
From: chasm@killer.DALLAS.TX.US (Charles Marslett)
Newsgroups: comp.sys.ibm.pc,comp.sys.intel
Subject: Re: correct code for pointer subtraction
Summary: DAMN IT, 64K is 64K and an array is a block of components!!!!!
Message-ID: <6479@killer.DALLAS.TX.US>
Date: 18 Dec 88 17:58:46 GMT
References: <15891@iuvax.cs.indiana.edu>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 48

In article <15891@iuvax.cs.indiana.edu>, bobmon@iuvax.cs.indiana.edu (RAMontante) writes:
> chasm@killer.DALLAS.TX.US (Charles Marslett) writes:
> >
> >	[...]	  And subtraction of
> >pointers OUGHT TO BE portable (to reiterate my original statement, the
> >Microsoft and Borland compilers are broken since they do not work "right").
> 
> I don't buy this; why do you say they don't work "right"?  Pointer
> subtraction is only valid when the pointers are to the same array, and
> TurboC (at least) is simply referencing off the DS register in small
> memory models.  So the pointers may be restricted in range, but they

An array is a set of elements, each the same size and same structure (this
applies to all the languages I am aware of, not just C).  The fact that the
original posting was not absolutely correctly written does not make what the
poster said wrong (spelling errors are reason for failure only in school).
The problem is not that pointers are restricted, the problem is that the
documentation says that small and compact model arrays cannot be bigger than
64K (total size), and large and medium model arrays cannot be bigger than 64K
each -- and the limit for references of the form "&array[k] - &array[m]" is
32K.  Either the compiler or the documentation is broken!

> should give the correct number of ELEMENTS (not bytes, unless  the array
> elements are byte-sized).

And the answer will wrong if the values are further apart that 32K bytes
(independent of the size of the element and the absolute value of the
difference -- if an element is 20K long, and the array has 3 elements,
&array[2] - &array[0] will give a NEGATIVE result *AND THAT IS WRONG*, I
repeat *THE COMPILER IS BROKEN*.

> Note that the original code in this thread made the mistaken assumption
> that its "diff()" function was dealing in pointers that were guaranteed
> to refer to the same array; in fact, they were independent pointers
> which happened, in the example call, to have received values based on a
> common array in the caller program.

I would say that this implies the compiler is broken if it does not generate
an error message since either the operation is legal and should generate a
valid result, or it is illegal, and should generate an error message.
> 
> Perhaps this discussion ought to move to comp.lang.c.

At last we agree!


Charles Marslett
chasm@killer.dallas.tx.us