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

[Reimar Döffinger]

On 27.08.2013, at 04:47, "Don Moir" <donmoir at comcast.net> wrote:

> ----- 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. 

Even older MSVC versions should figure this out and not warn about it, it definitely understands >> 32 (and I am fairly certain that in the case of MSVC we discussed this before, and I believed that you agreed there was no issue, so why does this come up again on an unrelated gcc thing?).
And "fixing" these kind of things in every single piece of software when it could be fixed properly in the compiler isn't exactly the right way.
We usually expect at least bug reports to be opened before working around issues in other project's code. That is the only way to give better solutions at least a chance.