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

[Ronald S. Bultje]

Hi,

On Mon, Nov 2, 2015 at 12:32 PM, Ganesh Ajjanagadde <gajjanag at mit.edu>
wrote:

> On Mon, Nov 2, 2015 at 11:58 AM, Ronald S. Bultje <rsbultje at gmail.com>
> wrote:
> > Hi,
> >
> > On Mon, Nov 2, 2015 at 11:07 AM, Ganesh Ajjanagadde <gajjanag at mit.edu>
> > wrote:
> >
> >> 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.
> >
> >
> > I'm not sure actually.
> >
> > I believe for new API you increment minor (see libavutil/version.h) by 1
> > and reset micro to 0. You bump major on API changes, and you bump micro
> for
> > behavioural changes (?).
>
> Hmm, then there is a micro bump that I missed: av_gcd works
> differently for negative inputs than before: previously it was
> undefined in terms of its documentation, not actuality I believe, but
> now it has well defined semantics for all int64_t, and this has been
> documented.


A micro does not have to be bumped on the very commit. We can merge that
micro-bump together for various features, or we can forget it altogether
and it's simply part of the next (totally unrelated) microbump. You can
even bump it today if there has not been a bump since already.

Regardless of when the micro was bumped after the fact, the application
that relies on the new/fixed/changed behaviour can then use that micro as
minimum required runtime version. That this was committed a month later is
merely a detail that most users will never know or care for.

Ronald