[FFmpeg-cvslog] r23904 - in trunk: cmdutils.h libavcodec/aac_parser.h libavcodec/ac3.c libavcodec/ac3.h libavcodec/ac3_parser.h libavcodec/ac3tab.c libavcodec/allcodecs.c libavcodec/alsdec.c libavcodec/avcodec.h l...

[Michael Niedermayer]

On Fri, Jul 02, 2010 at 03:26:29PM +0200, Diego Biurrun wrote:
> On Thu, Jul 01, 2010 at 05:44:22PM +0200, Michael Niedermayer wrote:
[...]
> The last time I remember us voting about something was whether or not
> warnings should be fixed.  In the preceding discussion you were clearly
> outnumbered already, it took a 10-1 (or so, I don't remember exact
> numbers) majority during the vote to sway you.

there was no such vote, at least not on ffmpeg-dev with vote in the subj

The closest i could find was a discussion about warnings
(subj:How to handle compiler warnings)
some quotes of that (in no particular order):

ivan:
    In MPlayer we already had incident. Diego fixed a warning in one way.
    Then he finds out that the fix gives different result than the old
    code and fixes it in another way. Then he gets flamed because the
    warning indicated actual bug and he had (re)committed buggy code, in a
    way that hides the warning. The whole issue was about trivial
    parenthesis.


Luca abeni:
    I agree about removing the number of warnings, if this is done in the
    correct way (avoiding useless casts, etc...); if there are warnings that
    cannot be removed without slowing down or obfuscating the code, maybe we
    should add a comment like
    /* The following line might generate a warning, because...
    * The warning cannot be easily removed without slowing the code because..
    */
    in the code. In this way, we can avoid having people that submit wrong
    patches for removing such warnings.
    
    Finally, maybe we can have a configure option for enabling all the
    possible warnings, and one for -Werror (both options disabled by
    default).


Roberti togni:
    > - have cleaner code,
    > - have important warnings not be drowned out,
    > - make FFmpeg a programming textbook.
    >
    > This does not include warning fixes that slow things down or obfuscate
    > the code, but if in doubt I personally would err on the side of fixing
    > the warning.
    >

    Ok for me as long as:
    - if there are useless warning, they are disabled instead of fixed
    - unclear cases are discussed first so that silencing a warning does
    not create a bug
    - we clearly decide which warnings must be fixed, since a warning-less
    compilation is a moving target (compiler and platform dependant)

discussed, ohh my, diego do you hear me, do you have amnesia?


Aurel:
    I disagree about turning on warning-is-error. Different compiler
    versions on different arch produce different warnings.
    With warning-is-error, building svn tree (our only supported
    distribution) will become a pain for non-developers.


Reimar:
    I am against hasty actions to fix things though, and disabling a
    particular warning should also be considered an option (I think we
    already disable some? And at least ICC is extremely noisy with some
    really irrelevant warnings IMO - assuming we even care about warnings of
    non-gcc).


myself:
    hmm i dont remember but i do remember diego breaking nut.c with a
    () warning fix :)
    Anyway it was fixed quickly IIRC ...
    
    I think the point to learn here is that warnings should be treated as
    potential bugs and be fixed with the neccessary care.

whatever happened in the last 2 years, lerning of that was not part of
it.

mans:
    > I think the point to learn here is that warnings should be treated as
    > potential bugs and be fixed with the neccessary care.
    
    Definitely.  That's why they're called warnings.


diego:
    OK, we pretty much seem to have consensus about this.  Should we add a
    paragraph about warnings to the policy?

my reply:
    yes

so where was the part of me disagreeing and that 10:1?
if the majority disgreed with someone then that someone was diego
who apparently wanted warnings removed at any cost, which no single other
developer wanted.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20100703/e07ced40/attachment.pgp>