[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