[FFmpeg-devel] [PATCH] libavutil: cast truncated valuestouint32_t

[Don Moir]

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

I believe I reported it way back and then reported by others and on and on... Still get the same old answer... Since there is only a 
few that generate such warnings in the public headers, seems it should be fixed in header. You can on about stupid compile but thats 
not going to help and everyone can just deal with it. It's not a big deal but I would prefer not to disable the warnings and 
everyone else can spend time dealing with it, reporting, or whatever.