[MPlayer-dev-eng] [rfc] committing rules and other policies

[Uoti Urpala]

On Sun, 2007-02-25 at 15:30 -0500, Rich Felker wrote:
> On Sun, Feb 25, 2007 at 11:37:53AM +0100, Luca Barbato wrote:
> >   - code compatibility (gcc version?)
> > 	do we really support gcc-2.95 (ppc does not, amd64 does not,
> > 	sparc does?, mips does?)?
> 
> Your mention of specific archs shows that the issue is not trivial to
> understand. These archs DO support gcc-2.95 because mplayer and ffmpeg
> are portable C code (C89 + minor C99 features that have been in gcc
> for over a decade)...aside from amd64 which is newer than gcc-2.95. :)
> The question here is whether the vector ops are supported.

gcc-2.95 might be able to parse the source file (after disabling vector
ops) on those platforms, but how well does the code it outputs run?
Support for non-x86 platforms improved a lot in later versions.

> The relevant principle here is principle of least dependency.
> Regardless of whether you want to explicitly support gcc-2.95 or not,
> there is no reason to introduce unnecessary dependency. That's the C89
> versus C99 issue.

True at the level of not introducing dependencies "just for fun", but
does not imply that gcc-2.95 should be supported. MPlayer *could* be
coded in pure C89 with anything else under #ifdef or not used at all.
That would be less dependencies on the compiler, but does not mean it
would be an improvement.

>  As far as I know, there's no remotely-working C
> compiler that does not support the minor C99 features MPlayer and
> ffmpeg are using now.

I'm not sure whether that is true about compilers specifically, but
there certainly are remotely-working (and better) system setups that
lack some feature but could be supported without major extra effort. I
see no reason why everything "remotely working" should be supported in
compilers but not in other system setup.

>  There are plenty of compilers that don't support
> full C99, _including_ latest gcc! So arguing that we should be free to
> use whatever C99 constructs we want is obviously nonsensical.

You're making a strawman argument. Nobody has argued for using full
variable-length array syntax.

> There are plenty of projects I've had some involvement with, such as
> ELinks, which insist on using pure C89 and seem to plan on doing so
> for the forseeable future. Any claim of "backwardsness" is just
> trolling. Well-managed projects will always follow a principle of
> least dependency.

There were lots of projects that used K&R C long after ANSI became the
standard (and perhaps still are some?). That doesn't mean using it was
recommendable in general or good even for many of the projects that did
it. Saying that anything "well-managed" must wait more than 10 years
before using any improvements in standards IS backwardsness.

> Then, there's a second inline asm syntax that keeps changing with
> every "modern" release of gcc. Following this new, moving target is
> akin to using the C++ language or writing Linux-kernel software. The
> rules keep changing under you.
>
> Here the answer is much less clear. There's no standard to go by. What
> MPlayer has been doing for x86, and what I believe is the correct
> solution according to the principle that forced upgrades are bad, is
> to follow the interface that's been stable for 10+ years, and restrict
> using constructs that worked in that old interface but that have been
> broken by recent instability.

Portraying gcc-2.95 as the "stable interface" and everything else as
"new, moving target" that "keeps changing with every release" is
dishonest. For example the new feature that probably creates the biggest
single improvement in asm readability and modifiability over gcc-2.95,
named asm arguments, is unlikely to disappear in future versions.

> FYI to the flamers^H: This is my last word on the issue in this
> thread. I don't intend to reopen old arguments and waste everybody's
> time. You know who you are and keep in mind that people are already
> mad enough at you right now...

Making claims and then implying that anyone who counters or disproves
them is just flaming is quite childish.