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

[Michael Niedermayer]

On Fri, Apr 02, 2010 at 03:33:55PM +0200, Stefano Sabatini wrote:
> On date Saturday 2010-03-27 00:51:13 +0100, Stefano Sabatini encoded:
> > On date Tuesday 2010-03-23 00:57:17 +0100, Stefano Sabatini encoded:
> > > On date Monday 2010-03-22 10:27:03 +0100, Michael Niedermayer encoded:
> > > > On Sun, Mar 21, 2010 at 10:51:12PM +0100, Stefano Sabatini wrote:
> > > > > On date Sunday 2010-03-21 22:38:28 +0100, Michael Niedermayer encoded:
> > [...]
> > > > AVERROR_NOTSUPP feels more toward a feature that can be supported but is not
> > > > we also might want to have a 
> > > > AVERROR_DISABLED for a feature suported but not compiled in
> > > > but then there is AVERROR_PATCHWELCOME and iam not sure what AVERROR_NOTSUPP is
> > > > supposed to mean then
> > > > anyway, error docs are poor and you are changing error code without their
> > > > meaning being clearly documented.
> > > 
> > > Description for AVERROR_NOTSUPP:
> > > #define AVERROR_NOTSUPP     AVERROR(ENOSYS)  /**< Operation not supported. */
> > > 
> > > Description for AVERROR_PATCHWELCOME:
> > > #define AVERROR_PATCHWELCOME    (-MKTAG('P','A','W','E')) /**< Not yet implemented in FFmpeg. Patches welcome. */
> > > 
> > > My interpretation of AVERROR_NOTSUPP:
> > > The *operation* requested is not legal/valid, as it is not supported
> > > by the element being requested.
> > > 
> > > So AVERROR_NOTSUPP should be returned just in case a certain operation
> > > is requested to an object for which that operation doesn't make sense
> > > / cannot be implemented, and in this sense is semantically near to the
> > > meaning of ENOSYS.
> > > 
> > > Think for example of a seek operation in a pipe, for which
> > > AVERROR_PATCHWELCOME wouldn't make sense.
> > > 
> > > I recognize though that the term "supported" in the "not supported"
> > > expression may lead to confusion, as it suggests what you said, so I'd
> > > suggest to use instead AVERROR_ILLEGALOPERATION or
> > > AVERROR_INVALIDOPERATION.
> > > 
> > > As for the distinction between AVERROR_DISABLED and
> > > AVERROR_PATCHWELCOME, I don't think that would be a good idea
> > > implementation-wise, as most of the time a program can't tell the
> > > distinction amongst the two.
> > > 
> > > For example av_error_input_format() doesn't know if it can't recognize
> > > a format because it has not been compiled in, because the format is
> > > not implemented, or because we inflicted to him bogus random data.
> > > 
> > > If you agree with the semantics I proposed, I'll post a patch for
> > > clarifying the description of AVERROR_NOTSUPP, also tell me what do
> > > you think about the AVERROR_INVALIDOPERATION rename.
> > 
> > Currently we have just one use of AVERROR_NOTSUPP:
> > 
> > in libavformat/file.c:
> > static int64_t file_seek(URLContext *h, int64_t pos, int whence)
> > {
> >     int fd = (intptr_t) h->priv_data;
> >     if (whence != SEEK_SET && whence != SEEK_CUR && whence != SEEK_END)
> >         return AVERROR_NOTSUPP;
> >     return lseek(fd, pos, whence);
> > }
> > 
> > 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,

no it is not,
Feature not implemented
and
Implementing this feature is welcome

are 2 seperate things

similarly

"not implementable"
"requested operation nonsensical"
"we dont want this implemented"
"disabled at compile time, rerun configure"

are all semantically different

also you cannot redefine the POSIX error codes to mean something else than
they mean.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100403/187204a8/attachment.pgp>