Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!amdahl!meccts!viper!john
From: john@viper.UUCP
Newsgroups: comp.lang.c
Subject: Re: Pointer Comparison and Portability
Message-ID: <541@viper.UUCP>
Date: Mon, 16-Feb-87 23:33:20 EST
Article-I.D.: viper.541
Posted: Mon Feb 16 23:33:20 1987
Date-Received: Tue, 17-Feb-87 23:08:43 EST
References: <416@vaxine.UUCP> <454@mipos3.UUCP> <636@sdchema.sdchem.UUCP>
Reply-To: john@viper.UUCP (John Stanley)
Organization: DynaSoft Systems
Lines: 73

In article <636@sdchema.sdchem.UUCP> tps@sdchemf.UUCP (Tom Stockfisch) writes:
 >
 >That is, even on a segmented architecture, when pointers get passed to a
 >subroutine, they MUST have distinct addresses -- how else can the subroutine
 >know what area of memory to access?
 >

  Tom, on segmented arcitecture machines you -could- have two distinctly
different pointer values which point to the same memory space.  This is
what Israel Pinkas was (I think) trying to point out.

  In the example he gave:
	  char p[16], q[16];
some compilers would take this and generate array addresses that start
in two different memory segments (segments on 80x86 machines are 64k bytes
long, but the actual starting memory location for two consecutive segments
are only 16 bytes away from each other...)

  This means the address of &p[0] could be 0001:0000 (segment:offset) and the
address of &q[0] could be 0002:0000.  Now, given that a compiler -could-
allocate and address the two arrays in this manner, the address for the
memory location &p[17] (incorrect, but technicaly a legal memory reference)
would be 0001:0010.  The byte of memory addressed by q[0] and p[17] would
be the exact same byte, but the two pointers 0002:0000 and 0001:0010 would be
different.

  If the people writing the compiler take this into account, it will require
converting all pointers used in pointer comparisons to a normalized form
which maps the entire memory space in a linear (one value per memory byte)
fashion.  Unfortunately, this also will slow down (rather nastily) all
operations using pointer comparisons...  An undesireable side effect for
a "feature" not defined in K&R.


  Getting back to the original starting question asked by Neil Webber:

>>Consider the following C function:
>>
>>        same_char (p, q)
>>        char *p;
>>        char *q;
>>        {
>>                return (p == q);
>>        }
>>
>>Does this function only return a non-zro value when p and q point
>>to the same physical character?

  The answer to the exact wording of the question is YES...  However....
saying that the function will ONLY return a non-zero value when the pointers
match is not the same as "Does the function ALWAYS return a non-zero value
when p and q point to the same physical character?"  The answer to the latter
question is NO.

  You can have
two different pointer values which point to the same physical character.
This is unusual, but it does happen in any instance where you might run
into a compiler which allocates memory in the manner I mentioned above.
The "solution" that I've used is, in any program I write where this might
have an effect, I define a macro PRTEQUAL(x,y).  On most machines I can
define this to be:
	#define PTREQUAL(x,y)	(x == y)
on any machine I port this code to which gives me problems, I can redefine
PTREQUAL (or PTRLESS, PTRGREATER, etc) to reference a function which does
the math necessary for linear mapping of the memory space.
  
  As long as you are referencing addresses within the same structure/array
you will not have to worry about this and the "same_char()" function you
wrote will work all the time.

-------------
john@viper.UUCP <John L. Stanley>
Analyst/Consultant - DynaSoft Systems...