🚀 go-pugleaf

[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.