On 12/15/2019 11:24 AM, Nicolas George wrote: > James Almer (12019-12-14): >> I'm not sure if this is a good idea. It takes any AVBufferRef as input, >> so it will crash on pretty much every one not created by an AVBufferPool >> (unless it checks that buf is not NULL before dereferencing it), or >> return something unrelated otherwise. > > This is true, but I do not consider it that big of a problem. It makes > no sense to access the opaque pointer unless you know precisely where > the buffer comes from and what the opaque pointer contains. This is only > expanding on this a bit. > > There are already several places in FFmpeg's API where parameters have a > constraint that cannot be expressed with the imperfect type system of > the C language. There are in the standard C library too: realloc() vs. > free(), pclose() vs. fclose(), etc. > > Regards,
Ok, if that's preferred then just adding a check for buf != NULL before dereferencing it should be enough. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
