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

[Michael Niedermayer]

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:
> > On Sat, Jul 17, 2010 at 03:37:51PM +0200, Stefano Sabatini wrote:
> > > On date Sunday 2010-04-04 04:05:23 +0200, Michael Niedermayer encoded:
> > > > On Sun, Apr 04, 2010 at 12:20:43AM +0200, Stefano Sabatini wrote:
> > > > > On date Saturday 2010-04-03 22:03:23 +0200, Michael Niedermayer encoded:
> > > > > > On Sat, Apr 03, 2010 at 05:08:48PM +0200, Stefano Sabatini wrote:
> > > > > [...]
> > > > > > > Regression test passed (both with LIBAVUTIL_MAJOR_VERSION == 50 and ==
> > > > > > > 51).
> > > > > > 
> > > > > > bumping it to 51 will changes the codes returned by all libs using libavutil
> > > > > > all of them would need to bump major.
> > > > > > i dont think this is reasonable, thus we should undo all error redefinitions
> > > > > > before they become real and debian burns you at the stake
> > > > > 
> > > > > /* the jackasses changed the error codes, so I need to build a
> > > > >  * backward compatibility layer */
> > > > > #if LIBFOO_VERSION < NEXT && LIBAVUTIL_VERSION_MAJOR > 50
> > > > > #define FOO_GET_AV_ERROR_CODE(err) (err == AVERROR_EOF         ? AVERROR(EPIPE ) : \
> > > > >                                     err == AVERROR_NUMEXPECTED ? AVERROR(EDOM)   : \
> > > > >                                     err == AVERROR_INVALIDDATA ? AVERROR(EINVAL) : err)
> > > > > #else
> > > > > #define FOO_GET_AV_ERROR_CODE(err) (err)
> > > > > #endif
> > > > > 
> > > > > 
> > > > > I'm not saying that's nice, but at least it is possible.
> > > > 
> > > > given the interresting cases ive seen with several shared libs and
> > > > dependancies amongth them i doubt anyone will come up with a variant
> > > > that works
> > > 
> > > I see the problem and I agree that the current solution is not
> > > acceptable, check attached.
> > > 
> > > Anyway the current solution is definitively not fine as well, we have
> > > two different error codes (AVERROR(EINVAL) and AVERROR_INVALIDDATA)
> > > which cannot be distinguished.
> > > 
> > > So I propose to defer that, while this shouldn't be done immediately,
> > > we should try to coordinate a major bump for all the libav* libraries,
> > > let's call it The Big Bump.
> > 
> > its scary what an error code bikeshed can lead to. 
> 
> > 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.


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



[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- 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/20100717/0b6ee481/attachment.pgp>