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

[Hendrik Leppkes]

On Mon, Nov 2, 2015 at 7:57 PM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> 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.
>

We don't really bump micro in the majority of cases anyway, not every
bugfix or change needs a bump.
Its more important to remember to bump minor when adding new API or
similar, so people can use that version to know if its present.

- Hendrik