[FFmpeg-devel] [PATCH] libavutil: cast truncated values touint32_t

Don Moir donmoir at comcast.net
Tue Aug 27 04:47:42 CEST 2013

----- Original Message ----- 
From: "Reimar Döffinger" <Reimar.Doeffinger at gmx.de>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Monday, August 26, 2013 10:38 PM
Subject: Re: [FFmpeg-devel] [PATCH] libavutil: cast truncated values touint32_t

> On 27.08.2013, at 04:09, Michael Niedermayer <michaelni at gmx.at> wrote:
>> On Mon, Aug 26, 2013 at 10:44:08PM +0200, Alfred E. Heggestad wrote:
>>> common.h   |    4 ++--
>>> rational.h |    2 +-
>>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>> 62a4072f9a04e905abe285fc98ecb7baeacad63a  0001-libavutil-cast-truncated-values-to-uint32_t.patch
>>> From fda5dcc3784be312a8242512a8df1e3dd197df77 Mon Sep 17 00:00:00 2001
>>> From: "Alfred E. Heggestad" <aeh at db.org>
>>> Date: Mon, 26 Aug 2013 22:31:43 +0200
>>> Subject: [PATCH] libavutil: cast truncated values to uint32_t
>>> programs using ffmpeg that are compiled with -Wshorten-64-to-32
>>> gives a warning when using header files common.h and rational.h
>>> cast 64-bit truncated values to (uint32_t) to avoid the warning
>> compilers dont print warnings for problems in system headers, the
>> libavutil headers are treated as such when installed.
>> can you elaborate on why this compiler "feature" doesnt work in
>> your case ?
>> fixing all warnings that any compiler with any option wth any header
>> could generate is not a trivial task and with some predantic warnings
>> might even be impossible
> Not to mention that in at least 2, if not all cases the compiler is being extremely stupid.
> It's trivial to prove that the result fits in 32 bit and thus there is no reason to warn.
> A compiler offering such an option should at least understand that (uint64 >> 32) fits in 32 bit.

The point is this is trival and the only warnings I get with msc from ffmpeg headers. So everyone dealing with it who cares turns 
the warnings off for ffmpeg which I don't like to do. It's reality and not to decide on compiler intelligence. 

More information about the ffmpeg-devel mailing list