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
signature.asc
Description: PGP signature
_______________________________________________ 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".
