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