[FFmpeg-devel] [PATCH] Fix MSVC warnings about possible value truncation.

Michael Niedermayer michaelni at gmx.at
Sat Aug 30 01:34:28 CEST 2014


On Sat, Aug 30, 2014 at 01:26:46AM +0200, Reimar Döffinger wrote:
> On 30.08.2014, at 00:44, Peter Kasting <pkasting at google.com> wrote:
> > Hi FFMPEG devs, please forgive any errors here as I'm normally a Chromium
> > developer and this is my first submission to FFMPEG.
> > 
> > The attached patch fixes instances of MSVC warning C4244 about possible
> > value truncation (e.g. when assigning double to float or int64_t to int).
> > This warning is currently disabled in Chromium's MSVC build and I'm trying
> > to enable it.
> > 
> > The patch touches a couple dozen files, however each file's changes are
> > basically standalone, so I could split this up into arbitrarily smaller
> > pieces, all the way down to one patch per file.  I'm happy to break this up
> > in any way desired if reviewers would prefer.  (One possibility would be
> > separate patches for each of the four directories touched.)
> > 
> > This is not a rubber-stamp review.  While I intended there to be no
> > discernable behavior change, it wasn't always clear what the best way to
> > fix each warning was.  I've marked cases in particular need of review with
> > "// !!! ..." comments asking what to do, but even in other places, in
> > particular floating-point casting changes where there may be precision
> > loss, reviewers should use care.
> 
> First, this needs very, very careful review. I am not at all convinced that these will not change behaviour.
> Second, I believe powf and sinf are less commonly available than pow and sin, so I think this will break compilation on some platforms (but haven't double-checked).

> Third, _if_ we want this, I would expect we want to enable the corresponding gcc warning as well. Only a minority of developers has access to MSVC and I consider this kind of thing not maintainable if most people will not get the warnings.

I think a key question is, what is the rate of warnings that point to
actual bugs vs. warnings that do not point to actual bugs.
is any of these changes fixing an actual bug ?

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140830/4d31bd8f/attachment.asc>


More information about the ffmpeg-devel mailing list