[FFmpeg-devel] [PATCH v1 2/2] libavformat/file: initilize the fd to -1 instead of 0(valid fd) in case unexpected file close

Limin Wang lance.lmwang at gmail.com
Sat Jul 13 01:36:28 EEST 2019


On Fri, Jul 12, 2019 at 10:44:48PM +0200, Michael Niedermayer wrote:
> On Tue, Jun 18, 2019 at 06:45:13PM +0800, lance.lmwang at gmail.com wrote:
> > From: Limin Wang <lance.lmwang at gmail.com>
> > 
> > Signed-off-by: Limin Wang <lance.lmwang at gmail.com>
> > ---
> >  libavformat/file.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/libavformat/file.c b/libavformat/file.c
> > index 08c7f8e6dd..40ae9ad2a8 100644
> > --- a/libavformat/file.c
> > +++ b/libavformat/file.c
> > @@ -274,6 +274,7 @@ static int file_open_dir(URLContext *h)
> >  #if HAVE_LSTAT
> >      FileContext *c = h->priv_data;
> >  
> > +    c->fd = -1;
> >      c->dir = opendir(h->filename);
> >      if (!c->dir)
> >          return AVERROR(errno);
> 
> Is it more robust to set fd=-1 after successfully opening the directory ?
> 
> considering that this could be already opened as a file ...
> (such combinations seem to be what the patch is about IIUC)
> and that on failure we could prefer to leave the state close to the
> original before the call
I'm using open the directory operation without any file combiations, if
the context need to support both dir and file combined, then I need do more
testing for the condition.

> 
> thanks
> 
> [...[
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> I have never wished to cater to the crowd; for what I know they do not
> approve, and what they approve I do not know. -- Epicurus



> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".



More information about the ffmpeg-devel mailing list