lör 2022-03-19 klockan 23:50 +0100 skrev Michael Niedermayer:
> On Mon, Mar 14, 2022 at 08:19:51PM +0100, Tomas Härdin wrote:
> > sön 2022-03-13 klockan 00:52 +0100 skrev Michael Niedermayer:
> > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
> > > ---
> > > libavformat/mxfdec.c | 8 +++++++-
> > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > index b85c10bf19..d7cdd22c8a 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -932,7 +932,13 @@ static int
> > > mxf_read_cryptographic_context(void
> > > *arg, AVIOContext *pb, int tag, i
> > >
> > > static int mxf_read_strong_ref_array(AVIOContext *pb, UID
> > > **refs,
> > > int *count)
> > > {
> > > - *count = avio_rb32(pb);
> > > + unsigned c = avio_rb32(pb);
> >
> > not uint32_t?
>
> we dont need an exact length variable here
Right, we don't support 16-bit machines
>
>
> >
> > > +
> > > + //avio_read() used int
> > > + if (c > INT_MAX / sizeof(UID))
> > > + return AVERROR_PATCHWELCOME;
> > > + *count = c;
> > > +
> >
> > This should already be caught by av_calloc(), no?
>
> the API as in the documentation of av_calloc() does not gurantee
> this.
Yes it does:
The allocated memory will have size `size * nmemb` bytes.
[...]
`NULL` if the block cannot be allocated
> Its bad practice if we write code that depends on some implementation
> of some code in a diferent module/lib
If av_calloc() does not guarantee this then it is useless. It is used
precisely for this all over the place. Are you going to change every
use of av_calloc() in mxfdec in the same way?
/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".
