🚀 go-pugleaf

In article <1992Nov19.061601.13164@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:
 > 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.

Well, examine the *as if* rule.  I think a run-time system is able to
move data under the proviso that it is able to identify all pointers
and update them accordingly; even if they are stored in non-pointer type
variables.  (I know of one Algol 68 garbage collector that did just that,
but it cheated.  On a tagged architecture it would certainly be possible.)
The questions answered are different from the question what happens if you
write a pointer to file and read it back in.  Let us rephrase:

	sometype *p = something;
	char save_p[sizeof(p)];

	(void)memcpy((void *)save_p, (void *)&p, sizeof(p));
	... many things happen here, except that all references to
	    something are still valid, whether something is moved or not
	(void)memcpy((void *)&p, (void *)save_p, sizeof(p));

Is it now guaranteed that 'p' still/again points to 'something'?
What is the answer if 'save_p' was modified and changed back in between?
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl