> 在 2021年4月20日，下午7:12，Michael Niedermayer <mich...@niedermayer.cc> 写道： > > On Tue, Apr 20, 2021 at 12:34:13PM +0800, Heng Zhang wrote: >> >> >>> 在 2021年4月19日，下午5:47，Michael Niedermayer <mich...@niedermayer.cc> 写道： >>> >>> On Mon, Apr 19, 2021 at 05:06:10PM +0800, a397341...@163.com >>> <mailto:a397341...@163.com> wrote: >>>> From: toseven <byone.h...@gmail.com> > [...] >>>> + if (ret < 0) >>>> + { >>>> + fprintf(stderr, "Error occurred in av_packet_add_side_data: %s\n", >>>> + av_err2str(ret)); >>>> + } >>>> + return ret; >>> >>> the { } placing style mismatches whats used in FFmpeg (i dont mind but some >>> people do mind) >>> >>> more general, how much code coverage is gained with these 2 fuzzers >>> compared to what already exists ? >>> >>> thanks >> >> Okay, I will modify my style to adopt for FFmpeg. What is more, I didn’t >> compare the code coverage between them. Do I have to do this? I mainly >> refer to the fate test from libavcodec/tests/avpacket.c and >> libavfilter/tests/formats.c. > > If code coverage does not improve, what would be the reason for FFmpeg to > include the code ?
Thank your reply. My fuzzing targets call the new API interfaces, which are not used by the existing fuzzing target. Though I don’t do the related experiment, code coverage should improve. > > Thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Republics decline into democracies and democracies degenerate into > despotisms. -- Aristotle > _______________________________________________ > 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". _______________________________________________ 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".
