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

[Rich Felker]

On Tue, Jul 11, 2006 at 09:54:10PM +0300, Uoti Urpala wrote:
> On Tue, 2006-07-11 at 10:05 +0200, Michael Niedermayer wrote:
> 
> > yes, id like to know that too ...
> > 
> > * mixing declarations and code, seems few really want that, my oppinion here
> >   is it might be nice in some cases but its not enough to drop support for a
> >   compiler ...
> 
> 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
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.

> > * 10 params asms (we also would have to drop support for several other gcc 
> >   versions)
> 
> Any idea which gcc versions those would be? I think few people would
> care about 3.0, 3.1 or 3.2. Debian stable has gcc 3.3 as the default gcc
> but it also has a gcc-3.4 package available, and installing it should be
> no harder than installing other MPlayer build requirements. Requiring
> 4.x would probably cause a sharper drop in users who could compile
> MPlayer without upgrading.

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
other 'broken' versions since they're all inferrior in all ways both
to gcc 2.95 and gcc 3.3/3.4/4.x. Whether Michael or someone else
cares, I dunno; you'll have to ask them.

> > * intrinsics, well gcc until 4.? generated terribly bad code for intrinsics
> > * some gnu stuff which would make mplayer no longer comple on iso-c compilers
> > 
> > anything else?
> 
> 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
initializers are also supported. VLAs are supported but buggy, and
AFAIK still buggy in gcc 3/4, but they work as long as you don't make
VLAs of aggregate types.

> 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.

Rich