On 2/20/2018 9:21 AM, wm4 wrote: > On Tue, 20 Feb 2018 08:47:51 -0300 > James Almer <jamr...@gmail.com> wrote: > >>> It has fully achieved its objectives. There's no more visible global >>> mutable state, and the actual global mutable state has been reduced to >>> less than 5 codec entries. >> >> It's true that after the deprecation period they will effectively be the >> only ones still mutable, but shouldn't the objective be to cover them all? > > That would be nice. But this has been discussed before. No kind of > different registration API could fix this issue either, unless we start > mallocing AVCodec structs and require the user to free them, or > something equally absurd. The proper solution for this specific issue > would be making a new API that somehow replaces AVCodec.pix_fmts. > >>> >>> Why are we discussing this _again_? >> >> Because a drawback has been found, namely that link time optimization >> using static libraries can't remove "non registered" modules anymore, >> and now depends fully on what's enabled at configure time. >> Ideally, a better registration based API that follows what i described >> above should be designed with care. > > Oh yeah, bikeshed attack by Michael. As it was said a few thousand times > already, public API users could NOT use the registration stuff to > register only specific components at runtime. So they have to use the > register_all variants, which pull in _all_ components even with static > linking.
Oh, i assumed it was possible to use avcodec_register() on a manual basis in a proper API usage scenario, but i see now that's not the case. Nevermind then, my argument was focused on preventing losing some link time optimization for static libraries assuming proper API usage. > > And that can't be made with dynamic linking either. If you statically > link anyway, you probably control everything, and you can configure this > stuff at compile time. > > Then I guess there's this very special case where a fuzzer statically > links to libavcodec, and registers only a few components (technically > violating the API and by guessing the component symbol name), and > without calling the register_all functions. This would make the > resulting executable much smaller, which is apparently important > because Google (who runs the fuzzers for their oss-fuzz project) is too > poor (?) to host all the statically linked fuzzers, _or_ the whitelist > stuff is not enough to trick the fuzzer into not trying to fuzz the > wrong code. In addition, it's apparently infeasible to just build > every fuzzer with a separate libavcodec. (Not sure about the details, it > was something like this.) > > Those requirements are really quite nebulous. I don't know why we even > should care - surely whoever does this will find a solution that works > for them. For example they could apply a small patch that makes the > codec_list[] symbol non-static non-const, which would allow them to > overwrite it (i.e. deleting unneeded entries). It's a really simple > solution that took me 5 minutes to come up with. Something like this is probably the best solution for the fuzzer issue, yes. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
