[FFmpeg-devel] av_open_input_file

[Michael Niedermayer]

On Sat, Dec 11, 2010 at 10:22:46AM +0100, Stefano Sabatini wrote:
> On date Friday 2010-12-10 16:43:04 -0800, Fabrizio Milo aka misto encoded:
> > Then the patch is much easier:
> > 
> > diff --git a/libavformat/avio.c b/libavformat/avio.c
> > index 9a4d735..33e6e58 100644
> > --- a/libavformat/avio.c
> > +++ b/libavformat/avio.c
> > @@ -190,7 +190,7 @@ int url_alloc(URLContext **puc, const char
> > *filename, int flags)
> >          up = up->next;
> >      }
> >      *puc = NULL;
> > -    return AVERROR(ENOENT);
> > +    return AVERROR(ENOSYS);
> >  }
> > 
> >  int url_open(URLContext **puc, const char *filename, int flags)
> > 
> > I would go with ENOSYS: operation not supported.
> > 
> > ENOENT will and should be returned by the protocol->open() function
> > 
> > We are allocating memory here not validating the data itself.
> 
> Consider the case: url_alloc(&uc, "foo:bar.mov", flags)
> 
> this may fail either because:
> 1) the protocol "foo" exists but is not registered
> 2) the protocol "foo" doesn't exist at all
> 
> in the first case we should use ENOSYS, in the second maybe EINVAL is
> better as it may be a *configuration* error of the user supplying
> invalid parameters.

 -- Macro: int ENOSYS
     Function not implemented.  This indicates that the function called
     is not implemented at all, either in the C library itself or in the
     operating system.  When you get this error, you can be sure that
     this particular function will always fail with `ENOSYS' unless you
     install a new version of the C library or the operating system.

so no, ENOSYS is always wrong here

EINVAL could be used but its rather generic and doesnt detailedly say what
really went wrong ...


> 
> The problem is that url_alloc() has no way to distinguish between 1)
> and 2), so I suppose it's safe to use ENOSYS (but I still believe an
> UNKNOWN_FORMAT may help in this case).

no, UNKNOWN_FORMAT is wrong too

a AVERROR_NOPROTO to indicate that the protocol hasnt been registered would
be correct

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101211/ec31eb3d/attachment.pgp>