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 _______________________________________________ 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".
