On Tue, Mar 14, 2017 at 4:49 PM, wm4 <nfx...@googlemail.com> wrote: > On Tue, 14 Mar 2017 14:19:24 +0000 > Rostislav Pehlivanov <atomnu...@gmail.com> wrote: > >> On 14 March 2017 at 13:38, wm4 <nfx...@googlemail.com> wrote: >> >> > 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. >> > >> > >> 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. > > Feel free to send a patch to Libav. Hopefully I won't be the one who > allows subtle and pointless API divergence over silly reasons.
Using "API divergence" as an excuse to accept silly decision is equally silly, if not more so. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel