home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / std / c / 3418 < prev    next >
Encoding:
Internet Message Format  |  1993-01-25  |  3.7 KB
  1. Path: sparky!uunet!ogicse!decwrl!pacbell.com!rtech!ingres!mikes
  2. From: mikes@Ingres.COM (Mike Schilling)
  3. Newsgroups: comp.std.c
  4. Subject: Structure walking
  5. Message-ID: <1993Jan25.213543.25499@pony.Ingres.COM>
  6. Date: 25 Jan 93 21:35:43 GMT
  7. Article-I.D.: pony.1993Jan25.213543.25499
  8. Lines: 63
  9.  
  10. Background:  We'd like to store data in arrays of various structures
  11. in a platform-independent format so that we can subsequently retrieve them
  12. on various different platforms.  We don't want to write a separate routine
  13. for each structure type.  Instead, we propose to store a template
  14. indicating the type of each member in the structure being encoded,
  15. followed by a portable representation of each scalar; a single
  16. general-purpose routine would read or write an array of structures,
  17. driven by the template.
  18.  
  19. The tricky part is inferring the offset of each member within the structure.
  20.  
  21. Question 1:  Are the following assumptions valid for all C compilers?
  22. For (c)-(f), assume that the structure contains only scalar members.
  23.  
  24. (a) Each scalar type has an unambiguous alignment requirement.
  25. (b) Each scalar type's alignment requirement is a power of two.
  26. (c) The offset of the first member of a structure is 0.
  27. (d) The offset of the (n+1)th member of a structure is the offset of
  28.     the nth member of the structure, plus the size of the nth member,
  29.     rounded up to the alignment requirement of the type of the (n+1)th member.
  30. (e) The alignment required by the structure is equal to the most restrictive
  31.     alignment of any of its members.
  32. (f) The size of the structure is the offset of the last member of the structure,
  33.     plus the size of the last member, rounded up to alignment required
  34.     by the structure.
  35.  
  36. It appears that (a), (c), and (d) (at least) must be true for ANSI-compliant
  37. C compilers; the May '86 draft says the following:
  38.  
  39.     Each non-bit-field member of a structure or union object is aligned in an
  40.     implementation-defined manner appropriate to its type.
  41.  
  42.     Within a structure object, the non-bit-field members and the units in which
  43.     bit-fields reside have addresses that increase in the order in which they
  44.     are declared.  A pointer to a structure object, suitably cast, points to its
  45.     initial member or, if it is a bit-field, to the unit in which it resides.
  46.     There may therefore be unnamed holes within or at the end of a structure,
  47.     but not at its beginning, nor more than necessary to achieve appropriate
  48.     alignment.
  49.  
  50. Question 2:  Can the assumptions in question 1 be generalized to include
  51. structures which contain nested structures?  Equivalently: if we "flatten"
  52. a structure (eliminate all nesting), will that leave its size, alignment
  53. requirements, and the offsets of its scalar members unchanged?
  54.  
  55. Question 3:  On at least one platform (Data General MV series minis),
  56. pointers to characters were represented diferently from pointers to anything
  57. else (really a byte pointer vs. word pointer distinction), so you had 
  58. to be very careful about how you cast pointers. 
  59. On such platforms, how are pointers to structures represented?  Does 
  60. it depend on the type of the structure?
  61. In particular, consider a structure whose sole member is a character.  
  62. Since pointers to all structures were represented as word pointers
  63. on those DG machines, this structure had to be word aligned, even though its
  64. contents only demanded byte alignment.  This violates 1e above.  Is the 
  65. assumption invalid, or did the compiler (which didn't claim to be 
  66. ANSI) non-conforming in that respect?
  67.  
  68. Mike
  69. ----------------------------------------------------------------------------
  70. mikes@ingres.com = Mike Schilling, INGRES, An ASK Group Company, Alameda, CA
  71. Just machines that make big decisions,
  72. Programmed by fellows with compassion and vision.    -- Donald Fagen, "IGY"
  73.