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

Rich Felker dalias at aerifal.cx
Thu Jul 13 09:51:18 CEST 2006


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




More information about the MPlayer-dev-eng mailing list