home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / c / 2576 < prev    next >
Encoding:
Text File  |  1992-09-08  |  3.9 KB  |  91 lines
  1. Path: sparky!uunet!vnet.ibm.com
  2. From: dmm@vnet.ibm.com (dave)
  3. Message-ID: <19920906.095303.273@almaden.ibm.com>
  4. Date: Sun, 6 Sep 92 12:53:27 EDT
  5. Newsgroups: comp.std.c
  6. Subject: Re: How is struct assignment defined (idle query)?
  7. Organization: IBM Canada Lab
  8. News-Software: UReply 3.0
  9. X-X-From: dmm@vnet.ibm.com (Dave Mooney)
  10. References: <715547606snx@grendel.demon.co.uk> <Bu3FMw.II4@sneaky.lonestar.org>
  11. Lines: 78
  12.  
  13.             <1992Sep5.165014.7366@sq.sq.com>
  14.  
  15. In <1992Sep5.165014.7366@sq.sq.com> Mark Brader writes:
  16. >>> Does ANSI say that structure assignment is done by member-wise copy or
  17. >>> by bit-wise copying?
  18. >
  19. > (As I said earlier, I do not believe that the answer to this is clear.)
  20.  
  21. While the standard does not specify explictly one way or the other, the
  22. fact that the equality operator is not allowed on structs implies that
  23. member-wise copy is certainly allowed.  That is, since
  24.  
  25.   struct1 = struct2;
  26.   if ( struct1 == struct2 )
  27.     /* blah blah blah */
  28.  
  29. is not permitted, it would seem to me that the Committee was concerned
  30. that allowing such comparisons would force an implementation to maintain
  31. the integrity of the padding, either by explicitly zeroing it or by only
  32. doing bitwise copying.  I expect that they considered dictating
  33. implementation specifics to be outside their baliwick, so they ducked the
  34. issue by disallowing structure comparisons.  For this reason, I think
  35. that the Standard implicitly allows either bitwise or memberwise copy,
  36. depending on how a particlar implementation can best implement it.
  37.  
  38. Another consideration is that a structure inside a union is going to be
  39. subject to bitwise copying if assignment is done at the union level, so a
  40. sensible implementation will probably do bitwise copying of a structure
  41. anyway.  But the Standard does not demand this.
  42.  
  43. >> How would a standard-conforming program tell the difference?
  44. > Since the bitwise copy is a superset of the member-wise copy, a conforming
  45. > program might be able to tell the difference *only if* the standard
  46. > requires bitwise copying and the implementation copies member-wise.
  47. > If that *is* the case, the following program is (I hope) strictly con-
  48. > forming, but prints "Failure!" on an implementation which has certain
  49. > alignment properties and which does member-wise copying.
  50. >    main() {
  51. >         static struct {char a; long b; char c;} zeroes, *p;
  52. >         p = malloc (sizeof *p); if (!p) return 1;
  53. >         memset (p, 'X', sizeof p);
  54. >         *p = zeroes;
  55. >         if (memchr (p, 'X', sizeof p)) printf ("Failure!\n");
  56. >         return 0;
  57. >    }
  58. > Untested code, because I don't have an ANSI C compiler handy.
  59.  
  60. This isn't strictly-conforming, since it relies on implementation-defined
  61. behaviour (namely, if there is padding between structure members and what
  62. that padding looks like (maybe your compiler explitly sets it all to
  63. 'X')).  But the point is moot since the Standard does not demand bitwise
  64. assignment anyway.
  65.  
  66. Another case is IBM's C/370 compiler, which does *chunkwise* copy for
  67. mixed-alignment assignments between packed and unpacked structures.  That
  68. is, given
  69.  
  70.   struct s {                 +---+---+---+---+---+---+---+---+
  71.     char a;               x: | a |///|   b   |       c       |
  72.     short b;                 +---+---+---+---+---+---+---+---+
  73.     long c;
  74.   };                         +---+---+---+---+---+---+---+
  75.   struct s x;             y: | a |   b   |       c       |
  76.   _Packed struct s y;        +---+---+---+---+---+---+---+
  77.  
  78.   x = y;
  79.  
  80. 'a' is copied in one chunk, and 'b' and 'c' are copied in a second chunk.
  81. In this case, the padding vanishes during the copy, and reappears during
  82. a copy going the other way.  (This, of course, proves nothing, but it is
  83. an interesting case to consider).
  84.  
  85. dave
  86.  
  87. -------------------------------------------------------------------------
  88. Dave Mooney                                              dmm@vnet.ibm.com
  89.  C Set/2 Development, IBM Canada Lab, 844 Don Mills Rd, Toronto, Ontario
  90.             "If you've got a blacklist, I want to be on it"
  91.