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

Ronald S. Bultje rsbultje at gmail.com
Mon Nov 2 16:28:07 CET 2015


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.

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.


More information about the ffmpeg-devel mailing list