home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / std / c / 3059 < prev    next >
Encoding:
Internet Message Format  |  1992-11-23  |  1.5 KB
  1. Path: sparky!uunet!world!ksr!jfw
  2. From: jfw@ksr.com (John F. Woods)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Must an object remain in place? (was: fwrite+fread of pointer)
  5. Message-ID: <19173@ksr.com>
  6. Date: 23 Nov 92 11:28:37 EST
  7. References: <1992Nov18.104542.8499@thunder.mcrcim.mcgill.edu> <1992Nov19.061601.13164@sq.sq.com> <7951@charon.cwi.nl> <1992Nov21.110226.24705@sq.sq.com>
  8. Sender: news@ksr.com
  9. Lines: 22
  10.  
  11. msb@sq.sq.com (Mark Brader) writes:
  12. >> Well, examine the *as if* rule.  I think a run-time system is able to
  13. >> move data under the proviso that it is able to identify all pointers
  14. >> and update them accordingly; even if they are stored in non-pointer type
  15. >> variables.  (I know of one Algol 68 garbage collector that did just that,
  16. >> but it cheated.  On a tagged architecture it would certainly be possible.)
  17. >In theory maybe, but not in practice.   Consider that you can transform
  18. >a pointer to a character string with "%p" in sprintf(), do arbitrarily
  19. >complex operations on the characters which end up reproducing the same
  20. >string, then use "%p" in sscanf() to reconstruct the pointer, and the
  21. >result must compare equal to the original pointer.
  22.  
  23. That's a pretty strong requirement, I think, but still not quite enough to
  24. (by itself) ensure that the contents of pointer variables may not change
  25. during execution:
  26.  
  27.     printf("%p\n", ptr);
  28.  
  29. could yield something like "<The Object Named Fred-0007>", if the architecture
  30. supported some other constant naming scheme for objects other than their
  31. virtual bus addresses.
  32.  
  33.