home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / std / c / 3042 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  2.3 KB
  1. Path: sparky!uunet!mcsun!sun4nl!cwi.nl!dik
  2. From: dik@cwi.nl (Dik T. Winter)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Must an object remain in place? (was: fwrite+fread of pointer)
  5. Message-ID: <7951@charon.cwi.nl>
  6. Date: 20 Nov 92 00:44:00 GMT
  7. References: <15977@goanna.cs.rmit.oz.au> <1992Nov18.104542.8499@thunder.mcrcim.mcgill.edu> <1992Nov19.061601.13164@sq.sq.com>
  8. Sender: piet@cwi.nl
  9. Organization: CWI, Amsterdam
  10. Lines: 36
  11.  
  12. In article <1992Nov19.061601.13164@sq.sq.com> msb@sq.sq.com (Mark Brader) writes:
  13.  > The desire to not break this code is a fairly strong argument that
  14.  > objects should not be movable at all.  You might argue that maybe
  15.  > it would be safe to allow movement only in special circumstances, like
  16.  > when malloc() is called -- but when what if the comparison function
  17.  > is not the simple pstrcmp() but something complicated that itself
  18.  > calls malloc()?
  19.  > 
  20.  > But even if this argument is accepted, it only conveys intent.  As to
  21.  > the actual wording of the standard requiring objects not to move, the
  22.  > best I can come up with is the thing I already quoted: section 1.6/3.14,
  23.  > where an object is defined as *a* region of data storage.  My inter-
  24.  > pretation is that the singular wording implies one particular region
  25.  > for the life of the object, not merely one at a time.
  26.  
  27. Well, examine the *as if* rule.  I think a run-time system is able to
  28. move data under the proviso that it is able to identify all pointers
  29. and update them accordingly; even if they are stored in non-pointer type
  30. variables.  (I know of one Algol 68 garbage collector that did just that,
  31. but it cheated.  On a tagged architecture it would certainly be possible.)
  32. The questions answered are different from the question what happens if you
  33. write a pointer to file and read it back in.  Let us rephrase:
  34.  
  35.     sometype *p = something;
  36.     char save_p[sizeof(p)];
  37.  
  38.     (void)memcpy((void *)save_p, (void *)&p, sizeof(p));
  39.     ... many things happen here, except that all references to
  40.         something are still valid, whether something is moved or not
  41.     (void)memcpy((void *)&p, (void *)save_p, sizeof(p));
  42.  
  43. Is it now guaranteed that 'p' still/again points to 'something'?
  44. What is the answer if 'save_p' was modified and changed back in between?
  45. -- 
  46. dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
  47. home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
  48.