"Ronald S. Bultje" <[email protected]> writes: >> > // FIXME name? >> > +#if UNCHECKED_BITSTREAM_READER >> > # define SKIP_COUNTER(name, gb, num) name##_index += (num) >> > +#else >> > +# define SKIP_COUNTER(name, gb, num) name##_index = \ >> > + (gb)->size_in_bits_plus1 - name##_index < (num) ? \ >> > + (gb)->size_in_bits_plus1 : name##_index + (num) >> > +#endif >> >> Thinking more carefully about it, this addition is overflow-safe since >> the skip amount must be small and we require end padding. Your old >> version with FFMIN(size, index + num) is thus safe here after all, >> should it result in better code. > > Thinking about it, I don't think that's right. Padding can't overflow size > of int of buffersize in bytes, but size_in_bits is - well - in bits, so if > bits is MAXINT, then the addition can overflow even though the size of the > padded buffer is (1<<28) + padding_size. > > (Does that make sense?)
You're right, if the size_in_bits is greater than INT_MAX-32, it can overflow. If we require the _padded_ buffer to be at most INT_MAX/8 bytes, it's all safe however. We already (implicitly, probably should document) impose this maximum on the unpadded size. Reducing it by a few bytes seems acceptable if this allows faster code here. So, does the FFMIN() variant produce better code? -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
