[FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag

[Rostislav Pehlivanov]

On 4 February 2016 at 15:55, Derek Buitenhuis <derek.buitenhuis at gmail.com>
wrote:

> On 2/4/2016 3:48 PM, Rostislav Pehlivanov wrote:
> > The only reason this existed was to allow for old compilers to not
> > complain/compile the project's code. As far as I know, we no longer have
> > support for such compilers hence this flag has become useless and we
> > have no reason to continue dragging so much behind the current standard
> > of the C language.
>
> We do. Older MSVC (via c99conv), and I am sure others.
>

Do we even support MSVC versions old enough to error on compilation for
mixed declarations and variables? Will c99conv actually error if it
encounters such code?
As for the other compilers, I bet they're sufficiently old, disused and
miscompiling to possibly ignore them.


>
> > Michael Niedermayer has already expressed interest in removing said flag:
> > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/187833.html
>
> [...]
>
> > This will essentially help bring the project to near 21st century age
> > and finally allow for developers to save on line numbers by NOT having
> > to define the variable around which a for loop needs to iterate (e.g.
> > have for (int i = 0; i < N; i++) loops instead of having to define 'i'
> > at the start of the function like a normal variable), as well as more of
> > the syntactic sugar C99 permits.
>
> I do mind for loops, but I consider, along with VLAs, mixed code and var
> decls to be bad practice, myself. If you have a ton of variables declared
> at the top of blocks, I argue you have other issues. I also believe mixing
> code/var decls makes variable shadowing much easier. My 2 cents, for what
> little it is worth.
>
>
Nobody said anything about VLAs, and I agree they're evil. But like kierank
said, when using the bitstream reader you have to resort to ugliness just
to prevent the compiler from complaining. And as for tons of variables
declared at the top - you again can't do much other than split the function
into multiple functions, and then you start going into the void loop(struct
stuff *stuff, int loops) { int i; for (i = 0; i < loops, i++)
some_function(stuff) } territory which makes no sense.
Nothing prevents us from putting this in the coding guidelines if you
really think it's bad coding practice.