home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / c / 3318 < prev    next >
Encoding:
Text File  |  1993-01-03  |  2.9 KB  |  90 lines
  1. Path: sparky!uunet!crdgw1!rdsunx.crd.ge.com!bart!volpe
  2. From: volpe@bart.NoSubdomain.NoDomain (Christopher R Volpe)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Struct hack one last time (one last time)
  5. Message-ID: <1993Jan3.220729.9290@crd.ge.com>
  6. Date: 3 Jan 93 22:07:29 GMT
  7. References: <1992Dec31.153931.7495@hubcap.clemson.edu> <1993Jan1.173852.26630@taumet.com>
  8. Sender: volpe@bart (Christopher R Volpe)
  9. Reply-To: volpe@ausable.crd.ge.com
  10. Organization: GE Corporate Research & Development
  11. Lines: 76
  12. Nntp-Posting-Host: bart.crd.ge.com
  13.  
  14. In article <1993Jan1.173852.26630@taumet.com>, steve@taumet.com (Steve Clamage) writes:
  15. |> mjs@hubcap.clemson.edu (M. J. Saltzman) writes:
  16. |> 
  17. |> >In a previous article (now expired at my site), I asked if the
  18. |> >notorious "struct hack" was still conformant if the tail array in the
  19. |> >struct was of type other than char.  Since no-one ever replied, I'll
  20. |> >ask one more time.
  21. |> 
  22. |> I don't see that the type of the array makes any difference.
  23.  
  24. When dealing with malloced storage, it shouldn't, since such storage may be 
  25. used for an array of any type.
  26.  
  27. |> 
  28. |> I do believe that the hack is not strictly conforming, however, since
  29. |> you would be using array indices outside the declared array bounds
  30. |> (char or double makes no difference).  The results of doing so are
  31.  
  32. It's not outside the bounds of the malloced array.
  33.  
  34. |> undefined.  Nonetheless, I don't know of any implementations where this
  35. |> would not work.
  36. |> 
  37. |> I have thought of a plausible implementation where the struct hack
  38. |> would fail, however.
  39. |> 
  40. |> An implementation is allowed to add padding to the end of a struct.
  41.  
  42. Only for alignment purposes. The Standard is pretty clear on that.
  43.  
  44. |> Suppose that the implementation adds space to the end of each struct
  45. |> type where it encodes information used for run-time error checking.
  46. |> The struct hack would fail in this case, since it would overwrite data
  47. |> used by the run-time system.  I believe the implementation would still
  48. |> be conforming, since we are in the arena of undefined behavior.
  49.  
  50. I disagree that we are in the area of undefined behavior, but regardless,
  51. your implementation is non-conforming. Consider the following strictly
  52. conforming program:
  53.  
  54. int main(void)
  55. {
  56.   struct foo {
  57.     double field[1];
  58.   };
  59.  
  60.   struct bar {
  61.     double field[2];
  62.   };
  63.  
  64.   union both {
  65.     struct foo small;
  66.     struct bar big;
  67.   };
  68.  
  69.   union both bothvar;
  70.   bothvar.big.field[1] = 1.0;
  71.   bothvar.small.field[0] = 0.0;
  72.   return 0;
  73. }
  74.  
  75. Your hypothetical implementation would store padding at the end of each
  76. structure type in which it would record the dimensions of the "field" 
  77. member of each struct. But then writing into bothvar.big.field[1] would
  78. presumably overwrite this dimension information in bothvar.small, causing
  79. strange bounds errors when trying to write into bothvar.small.field[0].
  80.  
  81. |> -- 
  82. |> 
  83. |> Steve Clamage, TauMetric Corp, steve@taumet.com
  84.  
  85. -- 
  86. ==================
  87. Chris Volpe
  88. G.E. Corporate R&D
  89. volpecr@crd.ge.com
  90.