[FFmpeg-devel] [PATCH v2] avutil/mem: Add av_fast_realloc_array()

[Nicolas George]

Andreas Rheinhardt (12019-12-26):
> b) It guarantees to not allocated more than UINT_MAX - 1 elements, so
> the caller needn't check for overflow if the desired size is increased
> in steps of one.

This is preparing trouble for later, and as Michael pointed, it will not
work when the number of elements is stored in a signed integer. (It was
a mistake to use a signed integer in the first place, but that
particular mistake is already all over the place). I strongly suggest we
try to make things properly:

- Make nb_allocated and min_nb size_t as they should be.

- Do not hard-code UINT_MAX-1, make it an argument, max_nb: that way, if
  the index is an integer, just pass INT_MAX-1, and if it is properly
  size_t, pass SIZE_MAX-1.

- Since we can't pass a pointer to int as a pointer to size_t, add a
  small convenience wrapper av_fast_realloc_array_int() just to convert
  the type of nb_allocated. That's ugly, but I do not see a better
  solution. Or we can decide we must change the type of the size to
  size_t whenever we update code to use av_fast_realloc_array().

And while we are at it, I would like better:

- Alter ptr the same way nb_allocated is altered, and return a real
  error code in case of error. Otherwise, the caller has to guess that
  only AVERROR(ENOMEM) is possible, and we have seen that these
  assumptions and hard-coded error code have a way of overstaying their
  welcome.

Poor choice of types have caused problems in the past. They will cause
more problems as the memory of computers, and therefore the task we give
them, grow. Let us not cultivate them.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20191226/15ac00b7/attachment.sig>