[MPlayer-dev-eng] 1-element hack for flexible arrays (was: [PATCH] Drop support for gcc-2.95)

[Rich Felker]

On Thu, Jul 13, 2006 at 04:03:23AM +0300, Uoti Urpala wrote:
> On Wed, 2006-07-12 at 19:44 -0400, Rich Felker wrote:
> > The pointer could just as easily have come from:
> > 
> > struct blah *foo = malloc(size);
> > int *bar = (int *)((char *)foo + offsetof(struct blah, a);
> > 
> > This pointer "bar" will have the SAME value as foo->a, where
> > "int a[1];" is the last element of struct blah. Since both
> > expressions bar[1] and foo->a[1] are the same, how do you justify your
> > claim that the latter is invalid when the former is clearly valid?
> 
> In the latter case the compiler knows the array has size 1. Even if bar
> and foo->a would have the same value as pointers it doesn't mean the
> compiler can't use any other information. If it knows that foo->a is an
> array of size N, then it can assume that in "foo->a[n]" n < N. I don't
> think the argument "even if the pointer addition goes outside the
> current array object, the memory could be interpreted as a larger array
> object, and thus the addition in the small array is not undefined but
> must match the result in the larger one" is valid.

You can think that all you want, but there's no support in the spec.
Saying "foo->a is an array of size N" is true when considering foo->a
as a non-modifiable lvalue, but not when considering it as an rvalue
in the expression *(foo->a + 1). Here foo->a is not an array of size N
but a pointer to type int, pointing to an address within the object
obtained by malloc.

Rich