[FFmpeg-devel] [PATCH 0/2] first steps to resolving float to int undefined behavior

[Ganesh Ajjanagadde]

On Mon, Nov 2, 2015 at 10:28 AM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> Hi,
>
> On Sun, Nov 1, 2015 at 8:20 PM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
>
>> On Sun, Nov 1, 2015 at 7:59 PM, Ronald S. Bultje <rsbultje at gmail.com>
>> wrote:
>>
>> - I think the name of this function is confusing. The av_clip* namespace
>> > seems reserved for int to int clips, so using it for a float to int
>> > conversion with clip is kind of weird. I would use a different namespace
>> > for it.
>>
>> Mathematically, it is the same as clipping, albeit "lossy", but then
>> again all clipping is by nature "lossy" on inputs outside the clipping
>> range, hence the choice of name. Any ideas for a namespace for this?
>>
>
> Clip is the namespace for _just_ a clip. This function converts _and_
> clips. How about av_rint64_clip.

I like this name, thanks. Also, please tell me what to do about
version bumps etc, so that I can get this done for v2.

>
> This is modeled after llrint, except that we "rint" a int64_t instead of a
> long long (hence rint64 instead of llrint). The clip is an additional thing
> this function does, so rint64_clip.
>
>> So, finally, maybe I'm being pedantic now, but it seems one of these
>> usages
>> > overflows if we go over 2^64 = 16000 petabytes. Is that right? Do we
>> really
>> > care? I mean, we're talking ffserver here, ffserver has much bigger
>> issues
>> > than this.
>>
>> You are right, gave it as an illustration of API usage and an issue,
>> albeit not a terribly important one :) - user's config is an untrusted
>> file.
>
>
> It affects where it lives. I guess it's ok since it seems common.h is
> installed, so nevermind this.
>
> Ronald
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel