[FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[Michael Niedermayer]

On Mon, Feb 19, 2018 at 09:57:35PM +0100, Hendrik Leppkes wrote:
> On Mon, Feb 19, 2018 at 8:30 PM, Michael Niedermayer
> <michael at niedermayer.cc> wrote:
> > On Sun, Feb 18, 2018 at 05:58:16PM +0000, Josh de Kock wrote:
> >> This should be the last of the major API changes. I'm not entirely
> >> sure if I missed anything.
> >
> > Moving from a register based system where a user app can register
> > any subset to a system which registers all via an array will
> > increase the size of statically linked binaries for users only
> > using a subset.
> >
> 
> User apps did not have the ability to register a subset. How would
> they do that? They can't access the internals (ie. the ff_ references
> to those components)

I think you are mistaken here.

What you are thinking of here, i think is, that ff_* symbols are not
accessable to user apps. This is true with shared libs but the issue
above is primarely an issue with static linking. There the ff_* symbols
are available.

But much more important, we are designing a new API here, it doesnt matter
all that much what was possible, what matters is that it IS possible
and its IMHO not a obscure use case to want to only "register" parts that are
actually needed. Every security concious application that deals with
some standarized input from the net, like a browser, would IMHO want to
limit the parts that are enabled by as many and as hard ways as possible.


> That was only something some internal tools used, and you can probably
> find different options for dealing with those.

I can imagine some ways to hack around it, for the fuzzer yes, but a
clean way though proper public API (no ff_*, no #ifdefs around the array)
would seem better

So, yeah, i would prefer if a new API would allow registering subsets.

Without this and if the fuzzer runs out of diskspace someone will probably
need to hack around the new API so the arrays with all the pointers to
every part arent linked in. I may be missing some solution but this
sounds like a bunch of ugly code ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180220/8dc1e616/attachment.sig>