[FFmpeg-devel] [PATCH] avcodec/fft_template: Fix multiple runtime error: signed integer overflow: -1943918714 - 1935113003 cannot be represented in type 'int'

James Almer jamrial at gmail.com
Mon Jun 12 01:54:53 EEST 2017


On 6/11/2017 10:21 AM, Paul B Mahol wrote:
> On 6/11/17, Michael Niedermayer <michael at niedermayer.cc> wrote:
>> On Fri, Jun 09, 2017 at 09:07:39PM -0400, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Thu, Jun 8, 2017 at 8:57 PM, Michael Niedermayer
>>> <michael at niedermayer.cc>
>>> wrote:
>>>
>>>> On Thu, Jun 08, 2017 at 06:35:07PM -0400, Ronald S. Bultje wrote:
>>>>> Hi,
>>>>>
>>>>> On Thu, Jun 8, 2017 at 6:10 PM, Michael Niedermayer
>>>> <michael at niedermayer.cc>
>>>>> wrote:
>>>>>
>>>>>> Signed value in
>>>>>> Unsigned
>>>>>> INTeger type
>>>>>
>>>>> [..]
>>>>>> Both SUINT and unsigned should produce identical binaries
>>>>>
>>>>> This seems to go against the rule that code should be as simple as
>>>> possible.
>>>>>
>>>>> Unsigned is simpler than SUINT if the outcome is the same.
>>>>
>>>> You can simply add the part of my mail here as awnser that you snipped
>>>> away:
>>>>
>>>> "But it makes the code hard to understand and maintain because these
>>>>  values are not positive integers but signed integers. Which for
>>>>  C standard compliance need to be stored in a unsigned type."
>>>>
>>>> A type that avoids the undefinedness of signed but is semantically
>>>> signed is correct, unsigned is not.
>>>>
>>>> If understandable code and maintainable code has no value to you,
>>>> you would favour using single letter variables exclusivly and would
>>>> never use typedef.
>>>> But you do not do that.
>>>>
>>>> I fail to understand why you insist on using unsigned in place of a
>>>> more specific type, it is not the correct nor clean thing to do.
>>>
>>>
>>> It's not just me, it appears to be most of us. Can't you just step back
>>> at
>>> some point and be like "ok, I'll let the majority have their way"?
>>
>> I do not know what the majority prefers. What i see is that the
>> people objecting are always the same 3-4 people. And very often
>> they have no authorship or past activity in the code a patch is about.
>> At least none i could find quickly.
> 
> How dare you speak like that about me?
> 
> Do you think about yourself like holy cow in any aspect of FFmpeg,
> security or not.

Please, can we all calm down? This is escalating way too much...


More information about the ffmpeg-devel mailing list