[MPlayer-dev-eng] [PATCH] Drop support for gcc-2.95

[Rich Felker]

On Wed, Jul 12, 2006 at 09:46:27PM +0300, Uoti Urpala wrote:
> > > It's not all that clear, it depends on which "array objects" are
> > > considered, and those aren't all that precisely defined. I think the
> > > issue is that a standard-conforming implementation may assume that 'n'
> > > in "a[n]" is within the size of the array when it has explicitly known
> > > size, and specifically may optimize "i=a[n];" to "i=a[0];" when 'a' has
> > > type "type_t a[1];".
> > 
> > Again this is not valid. foo.a[n] is identical to *(foo.a+n), and it
> > is valid to access any object via a character pointer. Since you know
> 
> The question is whether anything guarantees foo.a+n is defined. The
> section about adding to pointers says the result is undefined unless
> foo.a points to an "element of an array object" (with objects that are
> not in an array considered as if they were one-element arrays) such that
> foo.a+n still fits in the array. There's a special case for char
> pointers elsewhere that says pointers to any object can be converted to
> character type pointers and increments up to the size of the object
> yield pointers to its bytes. I haven't studied the standard enough that
> I could be sure there are no other special cases which could affect the
> result anywhere, but those sections seem to leave foo.a+n undefined for
> all values of n except 0 and 1 (dereferencing the result in the 1 case
> being forbidden) at least when foo.a isn't a character array.

The standard guarantees that foo.a evaluates to a pointer to character
pointing to a location offsetof(struct whatever, a) bytes from the
beginning of the malloc'd block. It is semantically equivalent to any
other pointer to this byte, which means that foo.a[1] is an lvalue
referring to the next byte in the malloc'd block after the byte
overlapping foo.a.

If you look at the semantics for malloc and the definition of
"object", I think you'll find that the same is true for types other
than character.

Rich