On Wed, 8 Apr 2015, Diego Biurrun wrote:
On Tue, Apr 07, 2015 at 08:41:19PM +0200, Anton Khirnov wrote:
Quoting Diego Biurrun (2015-04-07 17:55:19)
On Sun, Apr 05, 2015 at 09:04:09AM +0200, Anton Khirnov wrote:
Quoting Diego Biurrun (2015-03-31 16:31:33)
+unsigned ff_els_decode_unsigned(ElsDecCtx *ctx, ElsUnsignedRung *ur)
+{
+ int i, n, r, bit;
+ ElsRungNode *rung_node;
+
+ if (ctx->err)
+ return 0;
+
+ /* decode unary prefix */
+ for (n = 0; n < ELS_EXPGOLOMB_LEN + 1; n++)
+ if (ff_els_decode_bit(ctx, &ur->prefix_rung[n]))
+ break;
+
+ /* handle the error/overflow case */
+ if (ctx->err || n >= ELS_EXPGOLOMB_LEN) {
+ ctx->err = AVERROR(EOVERFLOW);
+ return 0;
+ }
+
+ /* handle the zero case */
+ if (!n)
+ return 0;
+
+ /* initialize probability tree */
+ if (!ur->rem_rung_list) {
+ ur->rem_rung_list = av_mallocz(RUNG_SPACE);
This variable mixes malloc and realloc, that should not be done.
I switched it to get allocated by plain calloc().
eh...calloc?
What else do you want to use for zeroed memory instead of av_mallocz?
I'd rather use av_realloc + memset then; we should stick to the one set of
allocator functions we have. The only exception is when allocating memory
for an external lib which requires it to be freeable by normal free().
Also intermixing an initialized malloc with realloc sounds like a weird
usecase, potentially something that isn't completely thought through: You
do keep in mind that if you expand the allocation you'll need to manually
initialize the new region of the allocation yourself, right? So why not
manually initialize all of it to keep it explicit and consistent with the
rest of the realloc calls?
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
