[FFmpeg-devel] [PATCH 2/2] lavfi: make filter_frame non-recursive.

[Nicolas George]

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
> example).
> 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
> with.
> 
> 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
me.

Actually, no, that is a gross understatement. The real statement would
be: a sane discussion can not happen unless the other side makes the
same efforts.

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
   exist, actually).

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.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161117/9e6885b7/attachment.sig>