🚀 go-pugleaf

> Let's see if I can bring this into sharper relief by eliminating the
> file ...
> 
> int *p; int dummy; char tmp[sizeof(int *)];
> p = &dummy; memcpy(&tmp[0],&p,sizeof(int *));
>	 /* insert other code here, not touching any
>	    of these three variables, if you feel like it */
> memcpy(&p,&tmp[0],sizeof(int *));
>
> At this point, must p == &dummy?  Must a reference to *p access the
> same object a similar reference to dummy would?  Note that the two
> questions do not ask quite the same thing, I think.

First, the two questions *do* ask the same thing.  In the standard,
sections 3.3.8/6.3.8 and 3.3.9/6.3.9 (ANSI/ISO numbering) specify in part:

#  If two pointers to object ... types both point to the same object,
#  ... they compare equal.  ... If two pointers to object ... types
#  compare equal, they both are null pointers, or both point to the
#  same object, or both point one past the last element of the same
#  array object.

Since &dummy points to an object, this means that p==&dummy if and only if
p points to the same object.

I'd like to point out that, while the above example code looks contrived,
things like that *do* happen in commonplace programs, and therefore it
would break working code if objects could be moved at arbitrary times.
Consider *this* code:

	#include <comp/lang/c/FAQ-list.h> /* :-) */   /* for pstrcmp() */

	char *list[N_ENTRIES];
		/* read n (<= N_ENTRIES) strings into list */
	qsort (list, sizeof (char *), n, pstrcmp);

What else could qsort() be using to rearrange the list entries but memcpy()
or some functional equivalent?

The desire to not break this code is a fairly strong argument that
objects should not be movable at all.  You might argue that maybe
it would be safe to allow movement only in special circumstances, like
when malloc() is called -- but when what if the comparison function
is not the simple pstrcmp() but something complicated that itself
calls malloc()?

But even if this argument is accepted, it only conveys intent.  As to
the actual wording of the standard requiring objects not to move, the
best I can come up with is the thing I already quoted: section 1.6/3.14,
where an object is defined as *a* region of data storage.  My inter-
pretation is that the singular wording implies one particular region
for the life of the object, not merely one at a time.
-- 
Mark Brader		   "Doing the wrong thing is worse than doing nothing."
SoftQuad Inc., Toronto     "Doing *anything* is worse than doing nothing!"
utzoo!sq!msb, msb@sq.com		     -- Lynn & Jay: YES, PRIME MINISTER

This article is in the public domain.