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

[Uoti Urpala]

On Wed, 2006-07-12 at 23:30 -0400, Rich Felker wrote:
> On Thu, Jul 13, 2006 at 04:03:23AM +0300, Uoti Urpala wrote:
> > 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.

The following is listed as explicitly undefined behavior by the
standard: "An array subscript is out of range, even if an object is
apparently accessible with the given subscript (as in the lvalue
expression a[1][7] given the declaration int a[4][5])". I think this
contradicts your interpretation that the compiler would have to ignore
array size information and consider pointer arithmetic based on
subscripts to be limited by allocated memory only, and in fact rather
directly rules out the 1-element hack as defined behavior.