[MPlayer-cvslog] r27240 - trunk/configure

[Uoti Urpala]

On Sun, 2008-07-13 at 07:56 +0200, Reimar Döffinger wrote:
> On Sun, Jul 13, 2008 at 04:37:25AM +0300, Uoti Urpala wrote:
> > As I already said changing from gnu89 to gnu99 does not make it any more
> > a "GNU mode" than it already is. If the effect of commandline options
> > for some reason unexpectedly changes in some future version of GCC the
> > options MPlayer sets can be changed easily enough.
> 
> Uh, this assumes it will ever be noticed. One of the things Michael
> sees is involuntarily supporting gnuisms.

For that to cause any problems would require the following:
1) GCC behavior changes in such a way that -std=gnu99 asks for more GNU
extensions than the default. Unlikely to happen.
2) Nobody notices this change. Unlikely.
3) Code which unintentionally depends on that particular subset of
extensions whose availability depends on the -std switch difference is
added to MPlayer without anyone noticing it directly. (As long as we
expect some GNU extensions like "asm" to work under GCC they can't all
be disabled.)

And then if all that happens, the only result is that it takes a bit
longer to notice the problems on some non-GCC compiler.

Using -std=gnu99 in fact avoids at least two nonstandard features that
have been used in MPlayer and FFmpeg: the nonstandard GNU "inline"
behavior and compound literals as constant initializers.

There were multiple cases of nonstandard inline definitions that didn't
work under standard C rules.

At least FFmpeg had code like the following (though with another type):
int i = (int){0};
in a scope where a constant initializer is required. This isn't legal C,
but GCC accepts it in the default gnu89 mode. With -std=gnu99 it is not
accepted.
(Note that "int *p = &(int){0}" where the compound literal is used as an
argument to & IS legal.)