[FFmpeg-devel] [PATCH] Fix return value check for open()

[Martin Storsjö]

On Fri, 24 Jul 2009, M?ns Rullg?rd wrote:

> Martin Storsj? <martin at martin.st> writes:
> 
> > Hi,
> >
> > According to all manuals I've checked (both linux & darwin manpages, and 
> > msdn docs), open() returns exactly -1 on error, not any generic negative 
> > number. The attached patch fixes the return value check in 
> > libavformat/file.c.
> >
> > On WinCE, the return values from successful open() calls are negative 
> > sometimes, making url_open() calls fail randomly. This is fixed by the 
> > attached patch.
> >
> > diff --git a/libavformat/file.c b/libavformat/file.c
> > index da0ce15..d2cb530 100644
> > --- a/libavformat/file.c
> > +++ b/libavformat/file.c
> > @@ -51,7 +51,7 @@ static int file_open(URLContext *h, const char *filename, int flags)
> >      access |= O_BINARY;
> >  #endif
> >      fd = open(filename, access, 0666);
> > -    if (fd < 0)
> > +    if (fd == -1)
> >          return AVERROR(ENOENT);
> >      h->priv_data = (void *) (intptr_t) fd;
> >      return 0;
> 
> Patch looks OK.  That said, this is what SUSv3 says on open:
> 
>   Upon successful completion, the function shall open the file and
>   return a non-negative integer [...].  Otherwise, -1 shall be
>   returned [...].
> 
> So yes, checking for -1 is correct.  However, I consider other
> negative return values an OS bug.

Ok, anyone care to apply?

And yes, returning negative valued file descriptors isn't really pretty, 
but fixing it properly wouldn't be too easy either, without e.g. remapping 
the bits of the descriptor and wrapping every other function that uses 
such a descriptor...

// Martin