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,
--
Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
