Alex Converse <[email protected]> writes: > On Fri, Apr 29, 2011 at 7:44 AM, Ronald S. Bultje <[email protected]> wrote: >> Hi, >> >> On Wed, Apr 27, 2011 at 3:29 PM, Ronald S. Bultje <[email protected]> wrote: >>> --- >>> libavfilter/avfilter.c | 3 ++- >>> 1 files changed, 2 insertions(+), 1 deletions(-) >>> >>> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c >>> index 135b9ff..c71c046 100644 >>> --- a/libavfilter/avfilter.c >>> +++ b/libavfilter/avfilter.c >>> @@ -587,7 +587,8 @@ int avfilter_open(AVFilterContext **filter_ctx, >>> AVFilter *filter, const char *in >>> ret->av_class = &avfilter_class; >>> ret->filter = filter; >>> ret->name = inst_name ? av_strdup(inst_name) : NULL; >>> - ret->priv = av_mallocz(filter->priv_size); >>> + if (filter->priv_size) >>> + ret->priv = av_mallocz(filter->priv_size); >> >> Ping. Ugly or not, we're allocating zero bytes of memory here. >> >> My last try at convincing you crowd that this is relevant: we cannot >> distinguish proper return values (NULL) from errors (NULL) if size=0.
Yes, something must be fixed in these cases. >> The standard says so. If wanted I will also introduce a if >> (!ret->priv) return AVERROR(ENOMEM); and add a nice comment that /* >> this allocates the codec private data */ or something. More >> importantly, I can't run fate on my mac because half of avfilter >> breaks. >> > > You could do > "if(!ret->priv && filter->priv_size) > return AVERROR(ENOMEM);" > > but at that point you could just put an if around the malloc. The best approach probably depends on the specifics of each case. Do whichever makes more sense, is easier, or whatever. > so ok i guess +1 -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
