On 2012-11-29 00:08:52 +0000, Måns Rullgård wrote: > Janne Grunau <[email protected]> writes: > > > On 2012-11-28 23:52:27 +0100, Luca Barbato wrote: > >> On 11/28/2012 11:25 PM, Janne Grunau wrote: > >> > Fixes mov_svq3_aac__t_starcraft2_teasecinv2_h264.mov.SIGSEGV.d8a.664. > >> > > >> > Found-by: Mateusz "j00ru" Jurczyk > >> > CC: [email protected] > >> > --- > >> > libavcodec/svq3.c | 2 +- > >> > 1 file changed, 1 insertion(+), 1 deletion(-) > >> > > >> > diff --git a/libavcodec/svq3.c b/libavcodec/svq3.c > >> > index ac8d9c1..a04748b 100644 > >> > --- a/libavcodec/svq3.c > >> > +++ b/libavcodec/svq3.c > >> > @@ -786,7 +786,7 @@ static int svq3_decode_slice_header(AVCodecContext > >> > *avctx) > >> > skip_bits_long(&s->gb, 0); > >> > } > >> > > >> > - if ((i = svq3_get_ue_golomb(&s->gb)) == INVALID_VLC || i >= 3) { > >> > + if ((i = svq3_get_ue_golomb(&s->gb)) < 0 || i >= 3) { > >> > av_log(h->s.avctx, AV_LOG_ERROR, "illegal slice type %d \n", i); > >> > return -1; > >> > } > >> > > >> > >> Is INVALID_VLC value negative? > > > > no, 0x80000000. But arithmetic conversion saves us. > > Ouch, that's _really_ bad. The svq3_get_ue_golomb() return type is > (inexplicably) int, so returning that value entails a conversion with > implementation-defined behaviour. Most compilers leave the bits intact > in such conversions, but I'd rather not depend on it. Also, such code > is nothing short of obfuscated even if it does work reliably.
6.3.1.3 reads to me as if signed int to unsigned int conversion is well defined: | Otherwise, if the new type is unsigned, the value is converted by | repeatedly adding or subtracting one more than the maximum value | that can be represented in the new type until the value is in the | range of the new type.60) | | ... | | 60) The rules describe arithmetic on the mathematical value, not the | value of a given type of expression. Janne _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
