🚀 go-pugleaf

In article <1993Jan2.072908.21929@sq.sq.com>, msb@sq.sq.com (Mark Brader) writes:
|> > > [Is] the notorious "struct hack" was still conformant if the tail array
|> > > in the struct [is] of type other than char[?] ... My reading of the
|> > > earlier thread on this topic was that the hack was indeed legal, but
|> > > all the previous examples used an array of char in their examples.
|> > > Thus, is there any reason it would not be legal to declare:
|> > >	struct vector {
|> > >		int  size;
|> > >		double v[1];
|> > >	} *vec;
|> > > and then code (for example):
|> > >	vec = malloc(sizeof(struct vector) + (n - 1) * sizeof(double));
|> > >	vec->size = n;
|> > >	for ( i = 0;  i < vec->size;  i++ )  vec->v[i] = 0.0;
|> 
|> I previously believed that this code was indeed legal, but I have lately
|> come to the opposite opinion.  Return to the classic struct hack:
|> 
|> 	struct hack /* well, what else? */ {
|> 		int len;
|> 		char arr[1];
|> 	} *p;
|> 	p = malloc(sizeof(struct hack) + n-1);  /* where n > 1 */
|> 
|> In this, access to p->arr[1] is legal because p->arr decays to a
|> pointer which points to some element of the object returned by
|> malloc -- you can identify which one by using offsetof -- and
|> the pointer p->arr+1 also points to some element of this object,
|> thus meeting the requirement specified by 3.3.6/6.3.6.

Agreed.

|> 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];
  }

The above struct has one more element in the "v" field than the one
in question. Thus, even though &vec->v[1] may not point to a double that
would be an element of the malloced storage if viewed as an array of
doubles, it *would* point to a double that would be a (component of) an
element of the malloced storage if viewed as an array of "struct vec2". 
Thus, the legitimacy of the struct hack is restored.

-Chris

-- 
==================
Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com