[Ffmpeg-devel] compiler warnings

[Steve Lhomme]

Rich Felker wrote:
> On Wed, Mar 29, 2006 at 11:26:47AM +0000, Dieter wrote:
>>> don't be afraid of warnings.
>> Fixing compiler warnings is good engineering practice.
> 
> No, it's not. What if I made a compiler that prints a warning whenever
> getpwuid(getuid())->pw_gecos contains "Dieter"? :)
> 
> The point being: some compiler warnings are valid, others are idiotic.
> Warnings can be broken down into:
> 
> - cases where someone who does not know C might infer the wrong
>   behavior from reading the code (like if (a=b)...).
> 
> - cases where there is no legitimate purpose for the code (things like
>   if ((unsigned)x >= 0) or printf("%s", i)...)
> 
> - other cases i dont care to write about.
> 
> The second class should obviously be fixed. On the other hand fixing
> the first just makes your code less readable by bloating it with
> unnecessary parentheses and such. C has operator precedence, ==/=
> distinction, etc. for a reason.

Having to guess exactly how a C compiler process data to know exactly 
what is does is bad engineering. Even though the code is correct and 
small, it makes it harder to read by a large number of coders. Making 
the code easily readable is important to maintain the code, not wonder 
if the compiler has to be C90 or C99 or whatever to compile a line 
correctly.

That's why the famous quote from here "fix the compiler" is also not 
realistic in the real world. Most of the time you are given a compiler 
(and an IDE) that goes with the hardware you're working with (I'm not 
talking about PCs) and you just do with it. You'll just get fired if 
instead of fixing bugs you were saying your boss "it's not my fault, 
it's the compiler". It's an engineering practice that will get you nowhere.

Steve