home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / std / c / 3321 < prev    next >
Encoding:
Text File  |  1993-01-04  |  3.0 KB  |  64 lines

  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!uunet.ca!wildcan!sq!msb
  3. From: msb@sq.sq.com (Mark Brader)
  4. Subject: Re: Struct hack one last time (one last time)
  5. Message-ID: <1993Jan4.054502.18515@sq.sq.com>
  6. Organization: SoftQuad Inc., Toronto, Canada
  7. References: <1993Jan1.173852.26630@taumet.com> <1993Jan2.072908.21929@sq.sq.com> <1993Jan3.224501.9742@crd.ge.com>
  8. Date: Mon, 4 Jan 93 05:45:02 GMT
  9. Lines: 53
  10.  
  11. [See the earlier articles for the various declarations and definitions.]
  12.  
  13. > > In the other example using double, we still know that the pointer
  14. > > obtained by decay of vec->v points to a double which is somewhere
  15. > > within the object returned by the malloc(), but we do NOT know that it
  16. > > points to a double that would be an element of that object if we viewed
  17. > > it as an array of doubles.  And this distinction, I fear, is critical.
  18. >
  19. > Ah! But is that necessary? I don't think so. As long as it points to a double
  20. > that would be an element of that object if we viewed it as an array
  21. > of SOMETHING. Suppose we viewed the malloced storage as an array of
  22. > the following structs:
  23. >   
  24. >   struct vec2 {
  25. >     int size;
  26. >     double v[2];
  27. >   }
  28. > ... Thus, the legitimacy of the struct hack [for non-chars] is restored.
  29.  
  30. I take my rhetorical hat off to the ingenuity of this suggestion, but
  31. I don't believe it forms a valid argument.  In order to invoke 3.3.6/6.3.6
  32. on the array member v of the type struct vec2, I believe it would be
  33. necessary to actually use a pointer of type struct vec2 *.  In other
  34. words, the array reference vec->v[1] would have to be changed to
  35. ((struct vec2 *) vec)->v[1].  And of course this destroys the usefulness
  36. of the hack, since the real point is that you want to refer to v[j] for
  37. a value of j that isn't known in advance.
  38.  
  39. In addition, I don't think that anything constrains the types double[1]
  40. and double[2] to have the same alignment requirements as each other,
  41. and so, offsetof(struct vec, v) and offsetof(struct vec2, v) need not
  42. be the same.
  43.  
  44. In addition, note that "array of n doubles" is a different type from
  45. double, and may the implementation may impose alignment requirements on
  46. it for some reason, and that requirements may be different for different
  47. values of n since those create different types also.  The upshot is that
  48. offsetof(struct vec, v) and offsetof(struct vec2, v) may be different,
  49. and so the argument fails on these grounds as well.
  50.  
  51. (I can't think of a practical reason why an implementation *would* impose
  52. alignment requirements on "array of n doubles" stricter than those on
  53. double, or requirements varying according to n, but the standard seems
  54. to allow it.  Similarly, although I showed in my previous message why
  55. I think the struct hack for non-char types is illegal, I can't think of
  56. a reason why it would fail, other than on implementations with strict
  57. array bounds checking.  This is, however, not the point.)
  58. -- 
  59. Mark Brader, SoftQuad Inc., Toronto         "Don't get clever at 5PM Friday."
  60. utzoo!sq!msb, msb@sq.com                    -- Tony Van Vleck
  61.  
  62. This article is in the public domain.
  63.