[FFmpeg-devel] [PATCH] Revert redefinition of AVERROR_NUMEXPECTED and AVERROR_INVALIDDATA at the next major bump.

[Stefano Sabatini]

On date Saturday 2010-07-17 19:59:43 +0200, Michael Niedermayer encoded:
> On Sat, Jul 17, 2010 at 07:24:44PM +0200, Stefano Sabatini wrote:
> > On date Saturday 2010-07-17 18:25:10 +0200, Michael Niedermayer encoded:
[...]
> > > and i must say with all the flaming i do against gnu libc & co, one thing
> > > they do manage quite well and that is keeping ABI compatible and not bumping
> > > every libs major version when someone determines that their error
> > > codes fail to distinhuish invalid values from invalid data. 
> > 
> > libc is a C library, so it's not going to change interface so often,
> > FFmpeg is a quickly evolving library, and in this case the change is
> > required to overcome a limitation present since its beginning.
> > 
> > > 
> > > AVERROR_INVALIDDATA == AVERROR(EINVAL)
> > > you can though add a new define with a new value
> > 
> > Mmh something like this:
> > #define AVERROR_INVALIDDATA2 ...
> 
> i would give it a completely new name because it means something entirely
> different AVERROR_INVALIDDATA meant EINVAL.

Michael that's the interpretation that I always gave to them:

AVERROR(EINVAL): invalid parameters provided to some function /
invalid configuration provided to some element (e.g. an encoder,
muxer, filter, etc.).

AVERROR_INVALIDDATA: "Invalid data found when processing input"
the data processed by an element is not valid.

The first is a configuration error, the second is an error in the
media content provided to an element, so yes I consider them different
kinds of error.

> > and then change all the instances where it is used
> > AVERROR_INVALIDDATA, some could be done with an AVERROR_EOF2 and an
> > AVERROR_NUMEXPECTED2 (well to be honest I'd rather prefer to deprecate
> > that at all, as this is a too much specific error code), yet the bump
> > solution looks somehow "cleaner".
> > 
> > Anyway if people consider that overkill I'll consider the new defines
> > approach.
> 
> major bumping every lib that linked to libavutil because _you_ dislike
> that AVERROR_INVALIDDATA == EINVAL does not seem reasonable.
> Is there some bug this fixes? some feature request it implements?

No, but having two distinct errors issuing the same error code is
confusing, and a potential source of bugs. Also I'm not saying that
this is sufficient for bumping all libs major, what I'm saying is that
we'll have to do it anyway soon or later so we can try to coordinate
the thing and fix this issue.

Regards.