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-requ...@ffmpeg.org with subject "unsubscribe".
