[FFmpeg-devel] [PATCH 1/6] lavu/mem: add av_realloc_reuse() as a replacement for av_fast_realloc()

Andreas Rheinhardt andreas.rheinhardt at outlook.com
Wed Sep 28 18:33:02 EEST 2022


Tomas Härdin:
> ons 2022-09-28 klockan 12:48 +0200 skrev Anton Khirnov:
>>
>> +/**
>> + * Reallocate a data buffer, reusing the existing one if it is large
>> enough.
>> + *
>> + * This function is similar to av_realloc(), but optimized for cases
>> where the
>> + * buffer may grow significantly and is not expected to shrink.
>> + *
>> + * @param[in] ptr Previously allocated buffer, or `NULL`. If `ptr`
>> is `NULL`, a
>> + * new uninitialized buffer is allocated. `ptr` is invalidated when
>> this
>> + * function returns non-`NULL` and must be replaced with its return
>> value.
>> + *
>> + * @param[in,out] size Pointer to the allocated size of buffer
>> `ptr`. This
>> + * function updates `*size` to the new allocated size (which may be
>> larger than
>> + * `min_size`). `*size` is set to 0 on failure.
>> + *
>> + * @param[in] min_size Minimum size in bytes of the returned buffer.
>> + *
>> + * @return
>> + * - An allocated buffer (to be freed with `av_free()`) that is
>> large enough to
>> + *   hold at least `min_size` bytes. The first `*size` (value on
>> entry to this
>> + *   function) bytes of the buffer remain the same as the data in
>> `ptr`, the
>> + *   rest is uninitialized.
>> + * - `NULL` on failure, then `*size` is set to 0 and ptr remains
>> untouched.
>> + *
>> + * @see av_realloc()
>> + * @see av_fast_malloc()
>> + */
>> +void *av_realloc_reuse(void *ptr, size_t *size, size_t min_size);
> 
> Isn't it better to return int like av_realloc_array_reuse() and leave
> *ptr and *size untouched on error just as it does? If we're in the
> business of straightening this all out then having all functions work
> the same is less mental load down the line.
> 

IMO size should be unchanged on error, but returning an int is IMO
overblown. I only did it for my version because there is the possibility
of the multiplication overflowing, but that is not the case here.

- Andreas



More information about the ffmpeg-devel mailing list