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

[Nicolas George]

Andreas Rheinhardt (12019-12-26):
> I don't understand. Do you think that callers will take this as a blank
> cheque to not check at all?

No, I mean that using the wrong type will impose limitations on us
later, that will take work to resolve.

> My intention was actually to convert the types for every user of this
> function when using this function (see e.g. the -Matroska demuxer patch).

Good. Then by all means, let us use the right type directly.

> Do we have arrays where there is a need to go beyond the range of ordinary
> integers for the number of elements?

Probably not many right now. But the power an memory of computers
increase, the needs increase too: it is becoming more and more likely to
cause an actual problem; and at the same time, the cost of using the
proper type decreases.


> I'd like not to turn the int/unsigned version of av_fast_realloc_array()
> into a wrapper until there is a real case where an array is needed that
> doesn't fit into an int (or an unsigned).

This is a public API, once it is there, we are stuck with it, including
the types, good or bad. Therefore, I insist we use the proper type from
the start.

>					    And switching to size_t
> everywhere would increase the size of certain structures which I very much
> like to avoid (e.g. the size of every MatroskaIndex element would increase
> by eight bytes (for 64 bit systems)).

If you are worried about eight measly bytes, you should start by
rethinking the memory allocation strategy: having a mallocated dynamic
array costs way more than eight bytes.

But if you really need to scrimp and save, you still can, you just need
to use an intermediate variable when calling av_fast_realloc_array().

> That is certainly possible (if "alter ptr the same way nb_allocated is
> altered" means: Via a pointer to a pointer.

Yes, altering the pointer by pointer instead of returning it: that frees
the return value for an error code.

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/20191227/7014366c/attachment.sig>