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

[Howard Chu]

Stefano Sabatini wrote:
> On date Friday 2010-04-02 15:14:28 -0700, Howard Chu encoded:
>> 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

Pretty much, yes.

> 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.

Obviously if you really want to say "can be implemented" you could use 
PATCHWELCOME.

> 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.

IMO drawing these distinctions is not useful. When an end-user sees these any 
of these messages, 98% of the time the results are all effectively the same - 
the software you have in front of you can't do what you asked it to do, tough 
luck. If you're actually a programmer, and in a position to investigate the 
code, you will do so, regardless of which of these error messages shows up.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/