Re: [FFmpeg-devel] [PATCH 5/8] avformat/matroskaenc: Use av_fast_realloc_array for index entries

["Tomas Härdin" <tjoppen@acc.umu.se>]

ons 2022-07-06 klockan 17:10 +0200 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > tis 2022-07-05 klockan 22:26 +0200 skrev Andreas Rheinhardt:
> > > 
> > > -    entries = av_realloc_array(entries, cues->num_entries + 1,
> > > sizeof(mkv_cuepoint));
> > > -    if (!entries)
> > > -        return AVERROR(ENOMEM);
> > > -    cues->entries = entries;
> > > +    ret = av_fast_realloc_array(&cues->entries, &cues-
> > > > allocated_entries,
> > > +                                cues->num_entries + 1,
> > > +                                MAX_SUPPORTED_EBML_LENGTH /
> > > MIN_CUETRACKPOS_SIZE,
> > 
> > Looks fine since MAX_SUPPORTED_EBML_LENGTH <= INT_MAX. Even
> > SIZE_MAX /
> > MIN_CUETRACKPOS_SIZE would work. Maybe we can could switch
> > MAX_SUPPORTED_EBML_LENGTH to
> > 
> >  #define MAX_SUPPORTED_EBML_LENGTH FFMIN(MAX_EBML_LENGTH, SIZE_MAX)
> > 
> > ?
> > 
> 
> To quote the comment for MAX_SUPPORTED_EBML_LENGTH:
> "/* The dynamic buffer API we rely upon has a limit of INT_MAX;
>  * and so has avio_write(). */"
> And I don't get why MAX_SUPPORTED_EBML_LENGTH <= INT_MAX is even
> relevant here. (Do you worry that MAX_SUPPORTED_EBML_LENGTH /
> MIN_CUETRACKPOS_SIZE might not be representable in a size_t? Thinking
> about this, defining it as FFMIN3(MAX_EBML_LENGTH, INT_MAX, SIZE_MAX)
> is
> better.)

INT_MAX <= SIZE_MAX on all platforms I am aware of. Just thought we
might want to support absolutely gargantuan .mkv files. Leaving it as-
is is fine

/Tomas

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".