On Thu, 20 Jul 2017, Sean McGovern wrote:
After 95ce02b35d3d1bb16111031df1d82a6e4d894d36, the value of ret
was not guaranteed to be 0 by some compilers.
This description raises quite a bit of questions. The root cause for the
issue seems to be something different. I'm pretty sure the issue lies
here:
@@ -722,6 +722,7 @@ ff_rm_parse_packet (AVFormatContext *s, AVIOContext
*pb,
int *seq, int flags, int64_t timestamp)
{
RMDemuxContext *rm = s->priv_data;
+ int ret;
if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
rm->current_stream= st->id;
@@ -778,11 +779,15 @@ ff_rm_parse_packet (AVFormatContext *s, AVIOContext
*pb,
} else
return -1;
} else {
- av_get_packet(pb, pkt, len);
+ ret = av_get_packet(pb, pkt, len);
+ if (ret < 0)
+ return ret;
rm_ac3_swap_bytes(st, pkt);
}
} else
- av_get_packet(pb, pkt, len);
+ ret = av_get_packet(pb, pkt, len);
+ if (ret < 0)
+ return ret;
It's not entirely obvious, but actually gets pointed out by modern GCC:
https://fate.libav.org/x86_64-linux-gcc-7/20170717123417/compile
libavformat/rmdec.c: In function 'ff_rm_parse_packet':
libavformat/rmdec.c:787:7: warning: this 'else' clause does not guard...
[-Wmisleading-indentation]
} else
^~~~
libavformat/rmdec.c:789:9: note: ...this statement, but the latter is misleadingly indented as if it were guarded
by the 'else'
if (ret < 0)
^~
That's why the uninitialized ret could be used.
Or that's at least my take on it just from reading the code now - please
doublecheck.
// Martin
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
