[rtmpdump] patch: gcc -Wextra

[Howard Chu]

Peter Miller wrote:
> On Fri, 2011-04-08 at 11:34 -0700, Howard Chu wrote:
>> Peter Miller wrote:
>>> This patch adds the gcc -Wextra flag, and fixes all the warnings it
>>> produces.
>>
>> Rejecting this patch. The C standard specifies that structure elements after
>> the last explicitly initialized one are all zero-filled. Explicit
>> initialization is not required.
>
> Like many of gcc warnings, the virtue of -Wmissing-field-initializers
> (implied by -Wextra) is not immediately obvious.  The merit comes when
> you add another field to a struct, and the initializers (elsewhere in
> the code) become out-of-date, and non-obviously wrong (to the compiler
> at least).  With this warning enabled, the compiler will produce a
> warning for each point in the code where it is used, allowing inspection
> and correction if necessary.

Sorry, but this is just a crutch for lame programmers. If you're disciplined 
and never modify existing field definitions, and only append new definitions 
to the end of the struct, this is completely unnecessary.

If you don't do that you're an idiot.

> Unions are more difficult, because many compilers don't like
> initializers for them; and if they do permit them, the convention of
> initializing the first union member is not universal.  This is why I
> used the "static struct foo foo_zero; struct foo var = foo_zero;" idiom,
> because it ensures the union is initialized.  Another advantage of the
> static zero idiom is that *all* of the stucture is initialized,
> including any "gaps" between members -- this is important when using
> valgrind(1) to look for accesses to uninitialized memory, and other
> memory issues valgrind(1) is good for.

Actually no, it's *bad* for precisely this purpose. If you're accessing beyond 
a defined structure field, and into the invisible padding, and you have 
already statically initialized all the fields to zero, then valgrind *won't* 
detect it as an access to uninitialized memory. valgrind will only be able to 
tell you that you have a bug if you leave the padding undefined.

> So, yes, at first sight, this patch could look unnecessary, but in my
> experience, gcc warnings are very useful for finding problems before
> they happen.  No-one goes to the effort of writing gcc code for no
> reason, and all gcc warnings are there because they consistently find
> bugs.  All the false positives are worth it when gcc finds a bug for
> you, and this is why I use -Werror to turn warnings into errors.

Writing clean code is always a worthwhile goal. But relying on your machines 
to be smarter than you is an exercise in futility.