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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
