[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...
Sat Jul 3 14:16:42 CEST 2010
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):
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
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
> - 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?
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.
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
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
> 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.
OK, we pretty much seem to have consensus about this. Should we add a
paragraph about warnings to the policy?
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
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
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-cvslog