home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / std / c / 3034 < prev    next >
Encoding:
Text File  |  1992-11-18  |  3.0 KB  |  69 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!utcsri!geac!sq!msb
  3. From: msb@sq.sq.com (Mark Brader)
  4. Subject: Must an object remain in place? (was: fwrite+fread of pointer)
  5. Message-ID: <1992Nov19.061601.13164@sq.sq.com>
  6. Organization: SoftQuad Inc., Toronto, Canada
  7. References: <1992Nov13.184421.11065@taumet.com> <15977@goanna.cs.rmit.oz.au> <1992Nov18.104542.8499@thunder.mcrcim.mcgill.edu>
  8. Date: Thu, 19 Nov 92 06:16:01 GMT
  9. Lines: 58
  10.  
  11. > Let's see if I can bring this into sharper relief by eliminating the
  12. > file ...
  13. > 
  14. > int *p; int dummy; char tmp[sizeof(int *)];
  15. > p = &dummy; memcpy(&tmp[0],&p,sizeof(int *));
  16. >     /* insert other code here, not touching any
  17. >        of these three variables, if you feel like it */
  18. > memcpy(&p,&tmp[0],sizeof(int *));
  19. >
  20. > At this point, must p == &dummy?  Must a reference to *p access the
  21. > same object a similar reference to dummy would?  Note that the two
  22. > questions do not ask quite the same thing, I think.
  23.  
  24. First, the two questions *do* ask the same thing.  In the standard,
  25. sections 3.3.8/6.3.8 and 3.3.9/6.3.9 (ANSI/ISO numbering) specify in part:
  26.  
  27. #  If two pointers to object ... types both point to the same object,
  28. #  ... they compare equal.  ... If two pointers to object ... types
  29. #  compare equal, they both are null pointers, or both point to the
  30. #  same object, or both point one past the last element of the same
  31. #  array object.
  32.  
  33. Since &dummy points to an object, this means that p==&dummy if and only if
  34. p points to the same object.
  35.  
  36. I'd like to point out that, while the above example code looks contrived,
  37. things like that *do* happen in commonplace programs, and therefore it
  38. would break working code if objects could be moved at arbitrary times.
  39. Consider *this* code:
  40.  
  41.     #include <comp/lang/c/FAQ-list.h> /* :-) */   /* for pstrcmp() */
  42.  
  43.     char *list[N_ENTRIES];
  44.         /* read n (<= N_ENTRIES) strings into list */
  45.     qsort (list, sizeof (char *), n, pstrcmp);
  46.  
  47. What else could qsort() be using to rearrange the list entries but memcpy()
  48. or some functional equivalent?
  49.  
  50. The desire to not break this code is a fairly strong argument that
  51. objects should not be movable at all.  You might argue that maybe
  52. it would be safe to allow movement only in special circumstances, like
  53. when malloc() is called -- but when what if the comparison function
  54. is not the simple pstrcmp() but something complicated that itself
  55. calls malloc()?
  56.  
  57. But even if this argument is accepted, it only conveys intent.  As to
  58. the actual wording of the standard requiring objects not to move, the
  59. best I can come up with is the thing I already quoted: section 1.6/3.14,
  60. where an object is defined as *a* region of data storage.  My inter-
  61. pretation is that the singular wording implies one particular region
  62. for the life of the object, not merely one at a time.
  63. -- 
  64. Mark Brader           "Doing the wrong thing is worse than doing nothing."
  65. SoftQuad Inc., Toronto     "Doing *anything* is worse than doing nothing!"
  66. utzoo!sq!msb, msb@sq.com             -- Lynn & Jay: YES, PRIME MINISTER
  67.  
  68. This article is in the public domain.
  69.