On 14.11.2016 17:42, Nicolas George wrote:
> What about:
>
> struct AVFilterLink {
> ...
> #ifdef FF_INTERNAL_API
> #inclde "avfilterlink_internal.h"
> #endif
I suspect that having different sizes for the same struct in different
parts of the code base will upset some static analyzers.
(I'm thinking of cbmc.)
And rightly so, I'd say, because this can easily cause big trouble.
Consider the (not so) theoretical case of API users simply (and wrongly)
using the structs on the stack instead of dynamically allocating them.
With the internal pointer the internal struct gets allocated in the
respective init function and things mostly work fine, while with
your proposal this would cause out-of-bounds reads/writes, which
likely means an arbitrary code execution vulnerability.
Thus I strongly advise against using this approach.
On 14.11.2016 16:52, Nicolas George wrote:
> Sorry, this is bad design, I refuse to have that in my code. I want to
> write link->fifo the same way I write link->src or link->time_base. You
> can reject my proposals, sure, but I can reject any proposal that do not
> verify this property.
If you really care so much about this, you can make the struct completely
private and add getter/setter functions for those elements that need
public access.
Best regards,
Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
