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

[Rich Felker]

On Wed, Jul 12, 2006 at 01:48:40AM +0300, Uoti Urpala wrote:
> On Tue, 2006-07-11 at 17:27 -0400, Rich Felker wrote:
> > On Tue, Jul 11, 2006 at 09:54:10PM +0300, Uoti Urpala wrote:
> > > The cost of avoiding them is higher than just the lost usefulness. Once
> > > you get used to them in other code it's natural to write them quite
> > > frequently, and they appear in patches, so avoiding them requires
> > > several changes to code.
> > 
> > It's not natural to write them unless you just learned C a year or two
> > ago or unless you're a C++ coder. In any case allowing them is totally
> 
> I learned C long before C99 existed and have not programmed much in C++.
> It seems you're stuck with the first version of any tool your learn and
> hate every improvement and change after that but you should realize that
> doesn't always apply to others.

These personal attacks are ridiculous and are avoiding the point. I
like C99. I use compound literals and named initializers for struct
elements quite often because they improve readability and sometimes
make possible what would otherwise be difficult to write in C.

C++ declarations are not such a thing. I thought they were an
abomination when I first learned C++ and I still do now.

Now are you going to continue to be difficult and to be a
nuisance/troll/etc. or work on the useful stuff you're doing like
correct pts handling?

> > out of the question until you supply a patch to make gcc 2.95 compile
> > them and as far as I'm concerned it should be out of the question
> > forever.
> 
> > Also out of the question until you supply a patch to make gcc 2.95
> > handle inline asm with >10 args. If you do that I don't care about the
> 
> How about you maintain gcc 2.95 yourself if you want to keep using it?

No, how about you do so if you want to be able to otherwise break use
of MPlayer on a valid, possibly essential configuration.

> > > I was mainly thinking of C99 features like compound literals (which 2.95
> > > supports partially?)
> > 
> > These are fully supported by gcc 2.95. I use them all the time. Named
> 
> No they aren't. I tested it and my first testcase was miscompiled by
> gcc-2.95. Seems it considered the initialized value to be const when it
> wasn't.

Could you explain? Are you sure your example is valid C?

> > > and flexible array members. They're usually not
> > > hard to work around using C89 syntax but still allow for nicer code.
> > 
> > Flexible array members are in no way better than just including a
> > one-element array at the end of the structure, which is guaranteed to
> > work as a consequence of other requirements in the C standard.
> 
> Wrong again. The C99 rationale explicitly mentions that the one-element
> hack is undefined behavior, which was a reason to add flexible array
> members. It might work with gcc and most other compilers but it is NOT
> guaranteed by the C standard.

Other parts of the standard guarantee that it work, namely the
stipulation that structs with compatible initial member sequences must
be able to be accessed compatibly. Contrary to populat belief, this
imposes a _requirement_ that the compiler must order struct members in
the order the programmer writes them. Otherwise structs with a common
initial sequence could not be compatible. (And if you want to pretend
the compiler could detect such struct definitions and special-case
them, remember that they could be in different translation units.)

> Your post was weak flaming and rants combined with factually incorrect
> arguments. If you have to keep posting your rants at least try to get
> the facts straight.

I did. The fact that the ISO C committee can't figure out the
consequences of their own specification is irrelevant.

Rich