🚀 go-pugleaf

In article <9930@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>That's all wrong.  Pointers to the same object compare equal ...
Yes, I was off base in my earlier article.  But doesn't the standard permit
odd behavior in a case like the following:
    char a[LIMIT];
    char b[LIMIT];
    ...
    if (a+LIMIT == b) ...
It appears that a+LIMIT may compare equal to b, in which case
3.3.9 says they point to the same object (b[0]) -- this is what one would
expect if the hardware had a simple address space and the allocation happened
a certain way.  But doesn't the standard permit the behavior which happens
with large model compilers for MS-DOS, in which they point to the same object
and compare not equal?  I guess you're implying that the MS-DOS behavior
is covered by saying that a+LIMIT does not point to an object.

>(Except that certain operations not permitted of conforming applications
>might produce pointers that accidentally refer to the same location; but
>since that would be totally erroneous code, you shouldn't worry about it.)
The discussion in comp.lang.c arose from a question of how to detect erroneous
code, i.e. how to verify that a pointer argument points into a particular
array rather than contains garbage.  Erroneous code is definitely a concern.

It seems that the solution proposed (by Karl Heuer I think) which
compares the argument for equality against every element of the array would
do the job (inefficiently).  If the pointer argument "accidentally" pointed
into the array, it might or might not be caught.  But any pointer which
passes the test does point into the array.
--
Prescott K. Turner, Jr.
Software Development Technologies, Inc.
P.O. Box 366, Sudbury, MA 01776 USA         (508) 443-5779
UUCP: ...{harvard,mit-eddie}!sdti!turner    Internet: turner@sdti.sdti.com