home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / c / 3426 < prev    next >
Encoding:
Internet Message Format  |  1993-01-27  |  3.8 KB
  1. Path: sparky!uunet!mcsun!Germany.EU.net!news.netmbx.de!mailgzrz.TU-Berlin.DE!math.fu-berlin.de!ira.uka.de!sol.ctr.columbia.edu!emory!gatech!hubcap!ncrcae!ncrhub2!ncrgw2!psinntp!heimdall!thor!scjones
  2. From: scjones@thor.sdrc.com (Larry Jones)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Structure walking
  5. Message-ID: <565@heimdall.sdrc.com>
  6. Date: 26 Jan 93 15:44:26 GMT
  7. References: <1993Jan25.213543.25499@pony.Ingres.COM>
  8. Sender: news@heimdall.sdrc.com
  9. Lines: 75
  10.  
  11. In article <1993Jan25.213543.25499@pony.Ingres.COM>, mikes@Ingres.COM (Mike Schilling) writes:
  12. > Question 1:  Are the following assumptions valid for all C compilers?
  13. > For (c)-(f), assume that the structure contains only scalar members.
  14. > 
  15. > (a) Each scalar type has an unambiguous alignment requirement.
  16.  
  17. True, but the compiler may choose to use a stricter alignment than is
  18. actually required.
  19.  
  20. > (b) Each scalar type's alignment requirement is a power of two.
  21.  
  22. False.  The Standard contains no such guarantee.
  23.  
  24. > (c) The offset of the first member of a structure is 0.
  25.  
  26. True.  ANSI 3.5.2.1 Structure and Union Specifiers:
  27.     A pointer to a structure object, suitably converted, points to
  28.     its initial member (or if that member is a bit-field, then to
  29.     the unit in which it resides), and vice versa.  There may
  30.     therefore be unnamed padding within a structure object, but not
  31.     at its beginning, as necessary to achieve the appropriate
  32.     alignment.
  33.  
  34. > (d) The offset of the (n+1)th member of a structure is the offset of
  35. >     the nth member of the structure, plus the size of the nth member,
  36. >     rounded up to the alignment requirement of the type of the (n+1)th member.
  37.  
  38. False.  ANSI 3.5.2.1 (emphasis mine):
  39.     Each non-bit-field member of a structure or union object is
  40.     aligned in an implementation-defined manner *appropriate* to its
  41.     type.
  42. Note that it says "appropriate to", not "required by".  An
  43. implementation has a great deal of latitude in how it aligns members.
  44.  
  45. > (e) The alignment required by the structure is equal to the most restrictive
  46. >     alignment of any of its members.
  47.  
  48. True, but see (a).
  49.  
  50. > (f) The size of the structure is the offset of the last member of the structure,
  51. >     plus the size of the last member, rounded up to alignment required
  52. >     by the structure.
  53.  
  54. False.  ANSI 3.5.2.1 again:
  55.     There may also be unnamed padding at the end of a structure or
  56.     union, as necessary to achieve the *appropriate* alignment were
  57.     the structure or union to be an element of an array.
  58. Again, it says "appropriate", not "required".
  59.  
  60. > Question 2:  Can the assumptions in question 1 be generalized to include
  61. > structures which contain nested structures?  Equivalently: if we "flatten"
  62. > a structure (eliminate all nesting), will that leave its size, alignment
  63. > requirements, and the offsets of its scalar members unchanged?
  64.  
  65. The answers don't change if you allow nested structures but, since your
  66. assumptions don't hold, you can't flatten a structure and expect its
  67. size, alignment, and member offsets to remain the same.
  68.  
  69. > Question 3:  On at least one platform (Data General MV series minis),
  70. > pointers to characters were represented diferently from pointers to anything
  71. > else (really a byte pointer vs. word pointer distinction), so you had 
  72. > to be very careful about how you cast pointers. 
  73. > On such platforms, how are pointers to structures represented?  Does 
  74. > it depend on the type of the structure?
  75.  
  76. It is generally reguarded as true that the Standard contains sufficient
  77. requirements scattered about its various sections to require that all
  78. structure pointers have the same representation.  There is no guarantee
  79. that this representation is identical to the representation of any other
  80. pointer type, however.
  81. ----
  82. Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
  83. larry.jones@sdrc.com
  84. If I get a bad grade, it'll be YOUR fault for not doing
  85. the work for me! -- Calvin
  86.