On Tue, 14 Mar 2017 10:24:10 -0300 James Almer <jamr...@gmail.com> wrote:
> On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote: > > On 14 March 2017 at 11:29, Michael Niedermayer <mich...@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. If you don't like size_t, make Libav change it. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel