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

[Rich Felker]

On Thu, Jul 13, 2006 at 01:32:44AM +0300, Uoti Urpala wrote:
> On Wed, 2006-07-12 at 17:36 -0400, Rich Felker wrote:
> > 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.
> 
> But this is specific to char pointers only, based on the special case I
> mentioned.
> 
> > 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.
> 
> I see no reason why this would be guaranteed for any type other than
> char. If the current array explicitly has size 1 I see nothing which
> would force the implementation to have defined behavior for pointer
> additions which go outside the array. Only char pointers are guaranteed
> to continue iterating over a larger object.

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?

Rich