Michael Niedermayer: > On Fri, Dec 13, 2019 at 06:05:21PM +0100, Andreas Rheinhardt wrote: >> On Fri, Dec 13, 2019 at 5:56 PM Michael Niedermayer <mich...@niedermayer.cc> >> wrote: >> >>> On Fri, Dec 13, 2019 at 12:24:04PM +0100, Andreas Rheinhardt wrote: >>>> On Fri, Dec 13, 2019 at 3:07 AM Michael Niedermayer >>> <mich...@niedermayer.cc> >>>> wrote: >>>> >>>>> No testcase >>>>> >>>>> Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> >>>>> --- >>>>> libavcodec/hevc_mp4toannexb_bsf.c | 4 +++- >>>>> 1 file changed, 3 insertions(+), 1 deletion(-) >>>>> >>>>> diff --git a/libavcodec/hevc_mp4toannexb_bsf.c >>>>> b/libavcodec/hevc_mp4toannexb_bsf.c >>>>> index baa93628ed..e0d20a550c 100644 >>>>> --- a/libavcodec/hevc_mp4toannexb_bsf.c >>>>> +++ b/libavcodec/hevc_mp4toannexb_bsf.c >>>>> @@ -152,7 +152,9 @@ static int hevc_mp4toannexb_filter(AVBSFContext >>> *ctx, >>>>> AVPacket *out) >>>>> extra_size = add_extradata * ctx->par_out->extradata_size; >>>>> got_irap |= is_irap; >>>>> >>>>> - if (FFMIN(INT_MAX, SIZE_MAX) < 4ULL + nalu_size + extra_size) >>> { >>>>> + if (FFMIN(INT_MAX, SIZE_MAX) < 4ULL + nalu_size + extra_size >>> || >>>>> >>>> >>>> Up until now I thought that FFmpeg has some implicit assumptions: int >>>> having 32bit being one of them (the log2 functions depend on this). And I >>> >>> yes, that was from POSIX >>> >>> >>>> also thought that size_t being able to hold all the values of an unsigned >>>> was one of these implicit assumptions, too. Am I wrong on this? >>> >>> I was asking myself the same, and i couldnt really find anything where we >>> stated that previously so i added a FFMIN. >>> >>> In this case we would have to add lots of checks before av_malloc and >> other allocation functions that use size_t parameters in order to ensure >> that no loss of information happens when an int (or unsigned) is converted >> to size_t. In other words: We should not support such systems. > > If we would choose to support such platforms in the future then using our own > type thats the bigger of the 2 might make this relativly painless. But first > such a platform needs to be relevant for us and exist ... > And if we choose to assume things about these types, that should be in our > developer documentation. > > But to return to the patch here, do you want me to remove the FFMIN ? >
Yes, please do so. After all, as long as there is no platform relevant to us it is just an unnecessary complication/potential for confusion. - Andreas _______________________________________________ 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".