[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 10:24:21AM +0300, Uoti Urpala wrote:
> 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.

It does not, because of the nature of the object. The object is a
block of memory of N bytes obtained by malloc, not a structure or
array.

Moreover as I have said before, claims in the spec that something has
"undefined behavior" are contradictory and irrelevant when another
part of the spec defines the behavior.

Rich