[FFmpeg-cvslog] r18599 - trunk/libavcodec/xan.c

[Reimar Döffinger]

On Fri, Apr 17, 2009 at 09:21:21PM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> 
> > On Fri, Apr 17, 2009 at 10:05:27PM +0200, reimar wrote:
> >> Author: reimar
> >> Date: Fri Apr 17 22:05:27 2009
> >> New Revision: 18599
> >> 
> >> Log:
> >> Use sign_extend function instead of reimplementing it.
> >> 
> >> Modified:
> >>    trunk/libavcodec/xan.c
> >> 
> >> Modified: trunk/libavcodec/xan.c
> >> ==============================================================================
> >> --- trunk/libavcodec/xan.c	Fri Apr 17 22:01:45 2009	(r18598)
> >> +++ trunk/libavcodec/xan.c	Fri Apr 17 22:05:27 2009	(r18599)
> >> @@ -333,16 +333,10 @@ static void xan_wc3_decode_frame(XanCont
> >>              }
> >>          } else {
> >>              /* run-based motion compensation from last frame */
> >> -            motion_x = *vector_segment >> 4;
> >> -            motion_y = *vector_segment & 0xF;
> >> +            motion_x = sign_extend(*vector_segment >> 4,  4);
> >> +            motion_y = sign_extend(*vector_segment & 0xF, 4);
> >
> > Someone forgot to document sign_extend, should I be doing the "& 0xF"
> > or can I assume that any future optimized implementation will flush
> > the upper bits, too?
> 
> What do you mean?  sign_extend() fills the size of an int, whatever
> that happens to be, typically 32 bits.

Let me say it differently:
It is not documented if future implementations may assume
val < (1 << bits)
for example for a fixed value of "bits" and a machine with extremely slow
shifts and bit operations, someone might have the idea of implementing
it as
> if (val & (1 << (bits-1)))
>     val += ~0 << bits;