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

[Uoti Urpala]

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:
"If the compound literal occurs outside the body of a function, the
object has static storage duration; otherwise, it has automatic storage
duration associated with the enclosing block."

> > > 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];".