[FFmpeg-devel] [PATCH] silence "may be used uninitialized" warnings

Michael Niedermayer michaelni
Fri Sep 21 12:09:14 CEST 2007


Hi

On Fri, Sep 21, 2007 at 01:25:59AM +0200, Aurelien Jacobs wrote:
> Michael Niedermayer wrote:
> 
> > Hi
> > 
> > On Thu, Sep 20, 2007 at 11:00:02PM +0200, Aurelien Jacobs wrote:
> > > Hi,
> > > 
> > > This patch does $subj for 2 warnings.
> > > If this is acceptable, this could then be applied to all other such
> > > warnings (after carefully verifying that those warnings are really
> > > false positives).
> > > So is it acceptable ?
> > 
> > iam weakly against it, it makes the code harder to read, if you want to
> > know about uninitalized vars use valgrind it will tell you which really are
> > while gcc will miss most and most of what it reports will not be
> > uninitalized
> 
> I agree we can't trust gcc to report uninitialized vars. But I think we
> shouldn't disable entirely this warning, as it can sometimes help to
> spot obvious errors during development.

are the extra false warnings really a problem here, shouldnt you understand
the code you work with and see immedeatly that what is printed is unrelated
or related to your change?


> Now, silencing wrong warnings helps to make real useful warnings more
> visible, so I think it's worth doing it.
> I also agree that it makes the code slightly harder to read but it also
> add the information that someone checked that this variable is really
> not used uninitialized. So this can save some time for people doing
> further code review.
> Maybe using a shorter macro name would keep the code a bit more readable
> and thus this patch more acceptable ?
> Something like uninit(var) ? or uv(var) ?

iam against this even more than the original, the name must be choosen so
that a non ffmpeg devel who knows C well doesnt have to grep the source
to figure out what this does

otherwise working on ffmpeg for someone new would eventually become a
nightmare as the code would be full of things which require her to
search for what they do ...

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

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- 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-devel/attachments/20070921/5ea1c639/attachment.pgp>



More information about the ffmpeg-devel mailing list