[FFmpeg-devel] FFmpeg 3.3

[Rostislav Pehlivanov]

On 14 March 2017 at 13:38, wm4 <nfxjfg at googlemail.com> wrote:

> On Tue, 14 Mar 2017 10:24:10 -0300
> James Almer <jamrial at gmail.com> wrote:
>
> > On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:
> > > On 14 March 2017 at 11:29, Michael Niedermayer <michael at niedermayer.cc
> >
> > > wrote:
> > >
> > >>
> > >> What about the spherical API size_t / uint32_t issue ?
> > >> we can change it before the release but not after it
> > >>
> > >>
> > > IMO its better to have the same type on all platforms. It also doesn't
> make
> > > sense to use size_t for something describing a position.
> >
> > wm4 argued it would generate problems for being different than libav's.
> > We don't care about ABI compatibility anymore so struct field size or
> > position isn't a problem.
> >
> > What kind of trouble would having the function signatures use uint32_t
> > here and size_t on libav generate? It's technically breaking API
> > compatibility i guess.
>
> I'm mostly thinking about things like overflow checks. And of course,
> you know, the damn user API.
>
>
Since the only way to currently get the (float) value of the position on
any platform is to measure its size, convert it to bits and calculate the
limit and divide it, changing the type to a static wouldn't cause any
problems for someone already doing this and will keep compatibility with
libav. Someone who assumes size_t is always going to be 64 or 32 bits will
be disappointed when their code doesn't work on MIPS/32 bit stuff but its
their fault for incorrectly assuming that and its our fault for letting
this patch in with size_t in the first place, so we ought to fix it.