home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / c / 3422 < prev    next >
Encoding:
Internet Message Format  |  1993-01-25  |  3.9 KB
  1. Path: sparky!uunet!olivea!decwrl!pa.dec.com!engage.pko.dec.com!nntpd.lkg.dec.com!jit345.bad.jit.dec.com!diamond
  2. From: diamond@jit345.bad.jit.dec.com (Norman Diamond)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Structure walking
  5. Message-ID: <1993Jan26.013634.20451@nntpd.lkg.dec.com>
  6. Date: 26 Jan 93 01:36:34 GMT
  7. References: <1993Jan25.213543.25499@pony.Ingres.COM>
  8. Sender: usenet@nntpd.lkg.dec.com (USENET News System)
  9. Reply-To: diamond@jit.dec.com (Norman Diamond)
  10. Organization: Digital Equipment Corporation Japan , Tokyo
  11. Lines: 74
  12.  
  13. In article <1993Jan25.213543.25499@pony.Ingres.COM> mikes@Ingres.COM (Mike Schilling) writes:
  14. >Instead, we propose to store a template indicating the type of each member
  15. >in the structure being encoded, followed by a portable representation of
  16. >each scalar;
  17.  
  18. And just write/read an array of chars, right?  Or use the XDR representations
  19. defined by one vendor (not standard but easy to use for your purposes).
  20.  
  21. >The tricky part is inferring the offset of each member within the structure.
  22.  
  23. Why is it insufficient to just use "offsetof" on each member?
  24.  
  25. >Question 1:  Are the following assumptions valid for all C compilers?
  26. >For (c)-(f), assume that the structure contains only scalar members.
  27.  
  28. >(a) Each scalar type has an unambiguous alignment requirement.
  29.  
  30. For all existing C compilers?  Probably.  For all hypothetical standard
  31. conforming compilers?  Uncertain.  Actually it is imaginable, for a
  32. hypothetical but really meaningful compiler, if space is virtually free
  33. but speed is extremely expensive, one might want to align a 4-byte integer
  34. in the second half of an 8-byte cache line in order to save time by only
  35. filling half of a cache line.  I don't know if you'd call this unambiguous.
  36.  
  37. >(b) Each scalar type's alignment requirement is a power of two.
  38.  
  39. For all existing C compilers, probably.  For all hypothetical standard
  40. conforming compilers, no, very clearly no.
  41.  
  42. >(c) The offset of the first member of a structure is 0.
  43.  
  44. Probably.  A structure pointer cast to the type of the structure's first
  45. member, or vice-versa, must still point to the right place.  And there cannot
  46. be a "hole" at the beginning of a structure.  I'm not sure if this proves
  47. that "offsetof" that member must yield a 0 result.
  48.  
  49. >(d) The offset of the (n+1)th member of a structure is the offset of
  50. >    the nth member of the structure, plus the size of the nth member,
  51. >    rounded up to the alignment requirement of the type of the (n+1)th member.
  52.  
  53. I think the answer to (a) fits here.
  54.  
  55. >(e) The alignment required by the structure is equal to the most restrictive
  56. >    alignment of any of its members.
  57.  
  58. No.  It seems to be mostly agreed (though I'm not sure if I agree) that the
  59. standard permits, and in some cases compilers do, align structures more
  60. strictly than the most restrictive alignment of any of its members.
  61. (This also answers part of your Question 3.)
  62.  
  63. >(f) The size of the structure is the offset of the last member of the structure,
  64. >    plus the size of the last member, rounded up to alignment required
  65. >    by the structure.
  66.  
  67. I think the answer to (a) fits again here.
  68.  
  69. Incidentally, it was not necessary to assume, for (c)-(f), that the structure
  70. contains only scalar members.  (This takes care of your Question 2.)
  71.  
  72. >Question 3:  On at least one platform, pointers to characters were represented
  73. >diferently from pointers to anything else
  74. >On such platforms, how are pointers to structures represented?
  75.  
  76. I think it's unspecified.  The implementation has to do something that will
  77. work, but I don't think they have to tell you what they've done.
  78.  
  79. >Does it depend on the type of the structure?
  80.  
  81. No.  The standard doesn't say, but someone has proven from other things that
  82. the standard says, that all structure pointers must be represented identically.
  83. --
  84. Norman Diamond                diamond@jit.dec.com
  85. If this were the company's opinion, I wouldn't be allowed to post it.
  86. Pardon me?  Or do I have to commit a crime first?
  87.