On Sun, 26 Oct 2014 00:16:26 +0200 Nicolas George <geo...@nsup.org> wrote:
> Le quartidi 4 brumaire, an CCXXIII, Michael Niedermayer a écrit : > > This fixes the issue that a not set or not forwarded whitelist > > would allow to bypass it. > > I am a bit worried by the sheer amount of extra code and API this simple > feature requires. Maybe it is a sign that it was not the best approach to > begin with. > > Also, I did not say at the time, but I believe using a string to hold a list > like that is quite ugly. > > Unless I am mistaken, the core of the problem resides in the existence of > global variables in the library, and this is not the only instance of this > issue: remember people who want to free the global mutex manager, not > understanding that "still reachable" is not a memory leak. > > There is an idea that I have been nursing for some time: moving all these > global variables to a structure, and start passing it around everywhere. > Most of the functions that access the global variables already have some > kind of context where the pointer can be stored, so it would only require > changing a few API entry points. > > That may look somewhat like that: > > AVCodecInstance *libavcodec = avcodec_library_create(OPTIONS); > AVFormatInstance *libavformat = avformat_library_create(libavformat, OPTIONS); > > avformat_instance_open_input(libavformat, &ctx, filename, NULL, NULL); > > Then the whitelist feature comes for free: use the options to disable > registering all the codecs, then manually register the ones needed. > > Of course, for compatibility, a global instance need to be inited if the > legacy entry points are used, but it becomes much easier to test extensively > that modern API usage will not touch them. > > Of course, that requires more work, and the whitelist feature will not be > available immediately, but in the long run I believe it would be greatly > beneficial. > > What do people think of that? That's exactly the same idea I suggested some hours ago on IRC - so it's not good, I guess? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
