[FFmpeg-devel] [PATCH 2/2] lavfi: make filter_frame non-recursive.
george at nsup.org
Thu Nov 17 18:47:36 EET 2016
Le quartidi 24 brumaire, an CCXXV, Hendrik Leppkes a écrit :
> If anything this discussion has shown that there are quite different
> priorities for many different developers.
> A key priority for many of us here seems to be to have a clean
> separation in public and private fields and keeping the public API
> clean and respectable (no weird ifdeffery in public headers, for
> We've had such a messy API for such a long time, so if we define any
> new solutions for the future, it should be one we can all be happy
> You seem to prefer a bit more internal simplicity over external
> interfaces, which is fine, but you should not expect everyone to share
> that preference.
I know all that. But that road works both ways. You can notice that I
did not sty to sneak that change within a huge complex patch, I
specifically called attention on it.
I realize that my proposal is not elegant.
More importantly, I realize it has practical drawbacks. I had not
thought of all that were raised in the discussion, and I thank the
people who did.
As a result, I have proposed various ideas for enhancing the proposal
and mitigating the drawbacks, while keeping the benefits I want from it.
I would appreciate of the other side would extend the same courtesy to
Actually, no, that is a gross understatement. The real statement would
be: a sane discussion can not happen unless the other side makes the
Here are three ideas to further reduce the drawbacks of my proposal.
All these are an alternative to the other suggestion of making
AVFilterLink suddenly opaque.
1. Filter the public headers before installing them, in order to
completely remove the internal fields. That way, the installed
headers are clean and not confusing for the users.
2. In the public view of the structure, instead of just removing the
internal fields, replace them with "char reserved[0xE000];". That
would completely close the risk of overflow for applications that
incorrectly allocate the structure themselves (which I do not think
3. For compilers where we know that works, replace that 0xE000 with
SIZE_MAX*7/16, making the structure impossible to allocate, thus
forbidding the invalid uses of the API.
Now, I realize that a lot of people will find these suggestions ugly.
They are, there is no doubt about it. But this is irrelevant: the
question is not "are they ugly?" but "are they uglier than the
alternative?", and your opinion on the matter can only be relevant if
you actually gave a solid amount of thought to the alternative.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Digital signature
More information about the ffmpeg-devel