[FFmpeg-devel] [PATCH 1/3] avformat/libquvi: fix error handling

[Michael Niedermayer]

On Wed, Apr 08, 2015 at 09:46:30PM +0200, Gilles Chanteperdrix wrote:
> On Wed, Apr 08, 2015 at 09:13:11PM +0200, Michael Niedermayer wrote:
> > On Wed, Apr 08, 2015 at 07:16:36PM +0200, Gilles Chanteperdrix wrote:
> > > avoid calling cleanup functions on uninitialized variables
> > > 
> > > Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix at xenomai.org>
> > > ---
> > >  libavformat/libquvi.c | 41 +++++++++++++++++++++++++----------------
> > >  1 file changed, 25 insertions(+), 16 deletions(-)
> > > 
> > > diff --git a/libavformat/libquvi.c b/libavformat/libquvi.c
> > > index 7c5f7a2..e838b34 100644
> > > --- a/libavformat/libquvi.c
> > > +++ b/libavformat/libquvi.c
> > > @@ -63,28 +63,38 @@ static int libquvi_read_header(AVFormatContext *s)
> > >      char *media_url, *pagetitle;
> > >  
> > >      rc = quvi_init(&q);
> > > -    if (rc != QUVI_OK)
> > > -        goto quvi_fail;
> > > +    if (rc != QUVI_OK) {
> > > +	av_log(s, AV_LOG_ERROR, "%s\n", quvi_strerror(q, rc));
> > > +	return AVERROR_EXTERNAL;
> > > +    }
> > 
> > is quvi_strerror() thread safe ?
> 
> I do not know, it was called in the original code, simply moved it
> around. 
> 
> Looking at the code, it would seem it is reentrant, with the state
> in quvi_t, so as long as the quvi_t is not moved around thread, this
> should be thread-safe.

yes, thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150408/61b416d3/attachment.asc>