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

[Rich Felker]

On Wed, Jul 12, 2006 at 07:54:10PM +0300, Uoti Urpala wrote:
> On Wed, 2006-07-12 at 12:29 -0400, Rich Felker wrote:
> > On Wed, Jul 12, 2006 at 10:26:41AM +0300, Uoti Urpala wrote:
> > > This is valid C. gcc-2.95 miscompiles it, resulting in a segfault on my
> > > machine.
> > 
> > It is NOT valid C. The compound literal exists only for the current
> > statement. After that it ceases to exist and any pointer to it is
> > invalid.
> 
> You seem to have quite bad misconceptions about C. From the standard:

So now we're even.

> > > > I did. The fact that the ISO C committee can't figure out the
> > > > consequences of their own specification is irrelevant.
> > > 
> > > I'm sure you understand the standard much better than those morons who
> > > wrote it.
> > 
> > They're not morons, but writing something does not necessarily mean
> > you've thought out every single implication of it. In fact that's
> > impossible. The only reason I was slightly mocking them is that they
> > intentionally said that the behavior is undefined (rather than saying
> > nothing) even though other parts of the spec clearly define it.
> 
> 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
(from other stipulations) what member and what alignment comes
immediately before the "a" element, you can use things like foo.a[-1]
to access it and there are well-defined results.

Also if the object being referenced came from malloc, then accesses to
memory beyond the end of the struct size are also well-defined, and
therefore must be able to be accessed as offsets from the address of
the "a" element, since "foo.a" simply evalutates to a pointer to an
address somewhere in the middle of the malloc'd object.

Thankfully C99 has finally built up enough of a specification that
most of the things that every sane person traditionally expected to
work in C are actually guaranteed to work, if only implicitly through
other requirements. The only sad exception I can think of right off is
signed right-shift.

Rich