Re: [PATCH] Deal with variable length arrays ending structures in get_base_and_extent

[Richard Guenther <rguenther at suse dot de>]

On Thu, 9 Feb 2006, Diego Novillo wrote:

> Daniel Berlin wrote:
> 
> >>> typedef struct { struct { int a[1]; } a[1]; } C;
> >>> int fooC1(C *c, int i, int d)
> >>> { 
> >>>   int j = i+i; 
> >>>   c->a[0].a[0] = j;
> >>>   return c->a[0].a[d]; /* Here we can propagate j */
> >>>
> >> You mean, "we can't", right?  You have no way of knowing if 'd == 0'.
> > 
> > You do know d == 0 (because the array size is only one element),  if it
> > wasn't for the stupid use of malloc tricks on arrays like the above.
> > 
> That's my point.  For better or for worse, the malloc tricks are
> allowed, so we can't assume d == 0.  Now, if the trick contravenes
> language standards, then *shrug*.

Actually in the case above you _can_ propagate j ;)  You can't, if the
expression would read c->a[d].a[0] -- at least that's what our consensus
at IRC was.  I.e. for clarity rename the structure elements as follows:

  typedef struct { struct { int inner[1]; } outer[1]; } C;

then c->outer[0] constrains the access to the structure element at
offset 0, size 4 (with the type struct { int inner[1]; }) due to
the constant offset.  And you can't possibly "escape" this access
by c->outer[0].inner[d] with arbitrary d.  In the case of
c->outer[d].inner[0] you of course have the possibly unconstrained
access to elements d>0 because of malloc tricks.

If you don't agree with the above, then the patch is wrong.

Richard.