Message ID | CAB0OVGoFawF8AUU7OXGFsZYc4aBTiBiDMGUpiO2p20YaDvpkog@mail.gmail.com |
---|---|
State | Superseded |
Headers | show |
On 2/4/2018 10:33 PM, Carl Eugen Hoyos wrote: > Hi! > > OOM is unlikely as a failure for avfilter_graph_alloc_filter(), the > patch avoids a surprising error if a filter was not found. > > Please comment, Carl Eugen > > > 0001-lavfi-avfiltergraph-Do-not-return-ENOMEM-if-filterch.patch > > > From 6587726a5e96570bb54e49ccf0b7fd6d94b929c8 Mon Sep 17 00:00:00 2001 > From: Carl Eugen Hoyos <ceffmpeg@gmail.com> > Date: Mon, 5 Feb 2018 01:43:08 +0100 > Subject: [PATCH] lavfi/avfiltergraph: Do not return ENOMEM if filterchain > init failed. > > A more likely reason is that the filter was not found. > --- > libavfilter/avfiltergraph.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c > index 4cc6892..7ccd895 100644 > --- a/libavfilter/avfiltergraph.c > +++ b/libavfilter/avfiltergraph.c > @@ -147,7 +147,7 @@ int avfilter_graph_create_filter(AVFilterContext **filt_ctx, const AVFilter *fil > > *filt_ctx = avfilter_graph_alloc_filter(graph_ctx, filt, name); > if (!*filt_ctx) > - return AVERROR(ENOMEM); > + return -1; -1 is not acceptable for a public function that states it returns an AVERROR value on failure. If the issue is that avfilter_graph_alloc_filter() may fail because of both OOM and an invalid value for filter, then I'm more inclined to use AVERROR_UNKNOWN here instead. That being said, based on the above the return value of avfilter_graph_alloc_filter() should have never been an AVFilterContext, but an int instead. Maybe a new function that returns a proper AVERROR value should be added. AVERROR(ENOMEM), AVERROR(EINVAL), AVERROR_FILTER_NOT_FOUND, or whatever corresponds depending on the type of failure. > > ret = avfilter_init_str(*filt_ctx, args); > if (ret < 0) > -- 1.7.10.4 > > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
On 2/4/2018 11:05 PM, James Almer wrote: > On 2/4/2018 10:33 PM, Carl Eugen Hoyos wrote: >> Hi! >> >> OOM is unlikely as a failure for avfilter_graph_alloc_filter(), the >> patch avoids a surprising error if a filter was not found. >> >> Please comment, Carl Eugen >> >> >> 0001-lavfi-avfiltergraph-Do-not-return-ENOMEM-if-filterch.patch >> >> >> From 6587726a5e96570bb54e49ccf0b7fd6d94b929c8 Mon Sep 17 00:00:00 2001 >> From: Carl Eugen Hoyos <ceffmpeg@gmail.com> >> Date: Mon, 5 Feb 2018 01:43:08 +0100 >> Subject: [PATCH] lavfi/avfiltergraph: Do not return ENOMEM if filterchain >> init failed. >> >> A more likely reason is that the filter was not found. >> --- >> libavfilter/avfiltergraph.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c >> index 4cc6892..7ccd895 100644 >> --- a/libavfilter/avfiltergraph.c >> +++ b/libavfilter/avfiltergraph.c >> @@ -147,7 +147,7 @@ int avfilter_graph_create_filter(AVFilterContext **filt_ctx, const AVFilter *fil >> >> *filt_ctx = avfilter_graph_alloc_filter(graph_ctx, filt, name); >> if (!*filt_ctx) >> - return AVERROR(ENOMEM); >> + return -1; > > -1 is not acceptable for a public function that states it returns an > AVERROR value on failure. > If the issue is that avfilter_graph_alloc_filter() may fail because of > both OOM and an invalid value for filter, then I'm more inclined to use > AVERROR_UNKNOWN here instead. > > That being said, based on the above the return value of > avfilter_graph_alloc_filter() should have never been an AVFilterContext, > but an int instead. > Maybe a new function that returns a proper AVERROR value should be > added. AVERROR(ENOMEM), AVERROR(EINVAL), AVERROR_FILTER_NOT_FOUND, or > whatever corresponds depending on the type of failure. Of course, assuming the actual reason of failure in avfilter_graph_alloc_filter is important only in avfilter_graph_create_filter and not really in any other situation, then an internal ff_graph_alloc_filter function could be added instead of a new public function for the above purpose. > >> >> ret = avfilter_init_str(*filt_ctx, args); >> if (ret < 0) >> -- 1.7.10.4 >> >> >> >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >
James Almer (2018-02-04): > -1 is not acceptable for a public function that states it returns an > AVERROR value on failure. > If the issue is that avfilter_graph_alloc_filter() may fail because of > both OOM and an invalid value for filter, then I'm more inclined to use > AVERROR_UNKNOWN here instead. Sounds reasonable. > That being said, based on the above the return value of > avfilter_graph_alloc_filter() should have never been an AVFilterContext, > but an int instead. > Maybe a new function that returns a proper AVERROR value should be > added. AVERROR(ENOMEM), AVERROR(EINVAL), AVERROR_FILTER_NOT_FOUND, or > whatever corresponds depending on the type of failure. I agree. In fact, would you support me if I propose to add the following policy:? Any new function av_something_alloc() should have an API: ret = av_something_alloc(&ptr, params); and not: ptr = av_something_alloc(params); even if it can, for the time being, only return AVERROR(ENOMEM). Regards,
On 2/5/2018 12:22 PM, Nicolas George wrote: > James Almer (2018-02-04): >> -1 is not acceptable for a public function that states it returns an >> AVERROR value on failure. >> If the issue is that avfilter_graph_alloc_filter() may fail because of >> both OOM and an invalid value for filter, then I'm more inclined to use >> AVERROR_UNKNOWN here instead. > > Sounds reasonable. > >> That being said, based on the above the return value of >> avfilter_graph_alloc_filter() should have never been an AVFilterContext, >> but an int instead. >> Maybe a new function that returns a proper AVERROR value should be >> added. AVERROR(ENOMEM), AVERROR(EINVAL), AVERROR_FILTER_NOT_FOUND, or >> whatever corresponds depending on the type of failure. > > I agree. > > In fact, would you support me if I propose to add the following policy:? > > Any new function av_something_alloc() should have an API: > > ret = av_something_alloc(&ptr, params); > > and not: > > ptr = av_something_alloc(params); > > even if it can, for the time being, only return AVERROR(ENOMEM). > > Regards, If it takes a parameter like the type of "something" you want to alloc then yes, I'd support that policy as there's no way to prevent the argument passed from being invalid, so NULL in that case will not mean ENOMEM but EINVAL. But if there's no parameters at all, or if the parameter is a size one, then the failure can only be OOM. In those cases I prefer the latter as it's more versatile in some situations, like using the function itself as an argument when calling another function.
James Almer (2018-02-05): > If it takes a parameter like the type of "something" you want to alloc > then yes, I'd support that policy as there's no way to prevent the > argument passed from being invalid, so NULL in that case will not mean > ENOMEM but EINVAL. Ok. > But if there's no parameters at all, or if the parameter is a size one, > then the failure can only be OOM. I can think of a few cases where the failure could be something else. For example if the structure that is allocated contains a mutex, the error could come from pthread_mutex_init(), which can return other errors than ENOMEM. > In those cases I prefer the latter as > it's more versatile in some situations, like using the function itself > as an argument when calling another function. That is true, but that also prevents from using the usual idiom: ret = ...; if (ret < 0) return ret; /* or goto fail */ It requires an extra "ret = AVERROR(ENOMEM)", plus the braces. I think this is more common than calling a function with the result without checking it. In terms of API regularity and simplicity, I find the hardcoding of AVERROR(ENOMEM) in the call site very distasteful. Regards,
On 2/5/2018 1:20 PM, Nicolas George wrote: > James Almer (2018-02-05): >> If it takes a parameter like the type of "something" you want to alloc >> then yes, I'd support that policy as there's no way to prevent the >> argument passed from being invalid, so NULL in that case will not mean >> ENOMEM but EINVAL. > > Ok. > >> But if there's no parameters at all, or if the parameter is a size one, >> then the failure can only be OOM. > > I can think of a few cases where the failure could be something else. > For example if the structure that is allocated contains a mutex, the > error could come from pthread_mutex_init(), which can return other > errors than ENOMEM. We ignore pthread_* errors as the wrappers (w32, os2) can only return 0. And afaik, things like this are why we many times provide both alloc() and init() functions. In any case, while i agree that returning an error value for future API additions should be heavily encouraged if not enforced for most cases, i insist that we should not outright forbid the addition of new simple malloc-wrapping functions, like the kind used to allocate structs where the size is not part of the ABI, as it's clear OOM will always be the only case of failure. See most alloc functions in lavu (crypto modules, packet/frame side data structs, etc). > >> In those cases I prefer the latter as >> it's more versatile in some situations, like using the function itself >> as an argument when calling another function. > > That is true, but that also prevents from using the usual idiom: > > ret = ...; > if (ret < 0) > return ret; /* or goto fail */ > > It requires an extra "ret = AVERROR(ENOMEM)", plus the braces. I think > this is more common than calling a function with the result without > checking it. > > In terms of API regularity and simplicity, I find the hardcoding of > AVERROR(ENOMEM) in the call site very distasteful. It has gotten a bit out of hand, true. That's why I'm with you that some rules needs to be defined. > > Regards, > > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
From 6587726a5e96570bb54e49ccf0b7fd6d94b929c8 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos <ceffmpeg@gmail.com> Date: Mon, 5 Feb 2018 01:43:08 +0100 Subject: [PATCH] lavfi/avfiltergraph: Do not return ENOMEM if filterchain init failed. A more likely reason is that the filter was not found. --- libavfilter/avfiltergraph.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c index 4cc6892..7ccd895 100644 --- a/libavfilter/avfiltergraph.c +++ b/libavfilter/avfiltergraph.c @@ -147,7 +147,7 @@ int avfilter_graph_create_filter(AVFilterContext **filt_ctx, const AVFilter *fil *filt_ctx = avfilter_graph_alloc_filter(graph_ctx, filt, name); if (!*filt_ctx) - return AVERROR(ENOMEM); + return -1; ret = avfilter_init_str(*filt_ctx, args); if (ret < 0) -- 1.7.10.4