[MPlayer-dev-eng] [PATCH] Drop support for gcc-2.95
dalias at aerifal.cx
Thu Jul 13 01:44:22 CEST 2006
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 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
> > 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;" is the last element of struct blah. Since both
expressions bar and foo->a are the same, how do you justify your
claim that the latter is invalid when the former is clearly valid?
More information about the MPlayer-dev-eng