Re: [FFmpeg-devel] [PATCH 2/2] avcodec/vp9.: Use av_malloc_array()

2014-08-25 Thread Ronald S. Bultje
Hi,

On Mon, Aug 25, 2014 at 12:47 PM, Michael Niedermayer michae...@gmx.at
wrote:

 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  libavcodec/vp9.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
 index 8f22685..241ea6c 100644
 --- a/libavcodec/vp9.c
 +++ b/libavcodec/vp9.c
 @@ -368,7 +368,7 @@ static int update_block_buffers(AVCodecContext *ctx)
  if (s-uses_2pass) {
  int sbs = s-sb_cols * s-sb_rows;

 -s-b_base = av_malloc(sizeof(VP9Block) * s-cols * s-rows);
 +s-b_base = av_malloc_array(s-cols, s-rows * sizeof(VP9Block));


How about av_malloc_array(s-cols * s-rows, sizeof(VP9Block))? Frame w/h
is 16bit limited, so rows/cols are naturally 13bits limited (since they are
in units of 8 pixels), so the product is 26bit max, so it won't overflow. I
don't even think the product of cols*rows*sizeof can overflow, but I guess
it is stylistically preferrable..

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 2/2] avcodec/vp9.: Use av_malloc_array()

2014-08-25 Thread Michael Niedermayer
On Mon, Aug 25, 2014 at 02:37:05PM -0400, Ronald S. Bultje wrote:
 Hi,
 
 On Mon, Aug 25, 2014 at 12:47 PM, Michael Niedermayer michae...@gmx.at
 wrote:
 
  Signed-off-by: Michael Niedermayer michae...@gmx.at
  ---
   libavcodec/vp9.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
  index 8f22685..241ea6c 100644
  --- a/libavcodec/vp9.c
  +++ b/libavcodec/vp9.c
  @@ -368,7 +368,7 @@ static int update_block_buffers(AVCodecContext *ctx)
   if (s-uses_2pass) {
   int sbs = s-sb_cols * s-sb_rows;
 
  -s-b_base = av_malloc(sizeof(VP9Block) * s-cols * s-rows);
  +s-b_base = av_malloc_array(s-cols, s-rows * sizeof(VP9Block));
 
 
 How about av_malloc_array(s-cols * s-rows, sizeof(VP9Block))? Frame w/h
 is 16bit limited, so rows/cols are naturally 13bits limited (since they are
 in units of 8 pixels), so the product is 26bit max, so it won't overflow. I
 don't even think the product of cols*rows*sizeof can overflow, but I guess
 it is stylistically preferrable..

ok

applied with that change

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel