[FFmpeg-devel] [RFC] The meaning of AVERROR_NOTSUPP

[Stefano Sabatini]

On date Friday 2010-04-02 15:14:28 -0700, Howard Chu encoded:
> Stefano Sabatini wrote:
[...]
> >>This suggests the interpretation of AVERROR_NOTSUPP as "Operation
> >>non-valid or illegal".
> >>
> >>Currently AVERROR_NOTSUPP is defined as AVERROR(ENOSYS), definition from [1]:
> >>|[ENOSYS]
> >>| Function not implemented. An attempt was made to use a function that
> >>| is not available in this implementation.
> >>
> >>Then we have the description of ENOTSUP, lexically close to AVERROR_NOTSUPP:
> >>|[ENOTSUP]
> >>| Not supported. The implementation does not support this feature of
> >>| the Realtime Option Group.
> >>
> >>Both these descriptions have some resemblance with the interpretation
> >>of AVERROR_NOTSUPP ->  feature not implemented.
> >>
> >>Since the semantics of AVERROR_NOTSUPP ->  feature not
> >>implemented is already covered by AVERROR_PATCHWELCOME, I suggest to
> >>prefer the semantics of AVERROR_NOTSUPP ->  operation non-valid or
> >>illegal.
> >>
> >>So I suggest to *rename* the symbol:
> >>AVERROR_NOTSUPP ->  AVERROR_INVALIDOPERATION
> >>
> >>and drop the old definition at the next major bump, and adopt the
> >>following description:
> >>"Invalid or illegal operation requested. An operation has been
> >>requested which does not make sense in the given context or cannot be
> >>implemented in the requested object."
> >>
> >>Comments are welcome, regards.
> >>
> >>[1] IEEE 1003.1 error code descriptions: http://www.opengroup.org/onlinepubs/000095399/functions/xsh_chap02_03.html
> >
> >See attached patches.
> 
> Seems to me you're trying to split hairs. Also, using these codes as
> you suggest will lend them false significance over time. E.g., the
> spec for a stream type may change in the future, and what was once
> illegal/invalid becomes legal. If you're reading the code and see
> INVALIDOPERATION you will simply dismiss this function as never
> being valid (when in fact you can never say never). It's better to
> leave the question open (not implemented today, can't say anything
> about the future).

What you're proposing if I understood it correctly is:

* to use AVERROR_PATCHWELCOME whenever there is a feature which is not
  implemented but which *can* be implemented

* to use AVERROR(ENOSYS) when a feature / function is not implementable
  or is not implemented but *may* eventually be implemented, for
  example if a given format is extended.

* to drop AVERROR_NOTSUPP

The problem is that the definition of ENOSYS is not clear about the
meaning of "not implemented", that could be interpreted for sure as
"not implemented but implementable, patches are welcome". Also it is
very specific about "functions" rather than features / operations.

Then there is the problem with the term "not supported" referenced in
AVERROR_NOTSUPP, which is naturally interpreted as "not supported in
the sense that it is currently not implemented, but can be
implemented", and doesn't say much about the reasons for which a
feature/function is not implemented, that's why I proposed the term
AVERROR_INVALIDOPERATION.

I reckon that the term AVERROR_INVALIDOPERATION may appear quite
unflexible and not future proof, but at least it has a semantics which
is orthogonal with respect to that of AVERROR_PATCHWELCOME. If a
non-implementable feature becomes implementable due to a format
extension, then the code can be changed to AVERROR_PATCHWELCOME.

Regards.
-- 
FFmpeg = Frightening and Free MultiPurpose Explosive Gymnast