Quoting Paul B Mahol (2020-10-06 10:19:13) > On Tue, Oct 06, 2020 at 10:08:58AM +0200, Anton Khirnov wrote: > > Quoting Paul B Mahol (2020-10-06 02:17:14) > > > Signed-off-by: Paul B Mahol <one...@gmail.com> > > > --- > > > libavcodec/apedec.c | 10 +++------- > > > 1 file changed, 3 insertions(+), 7 deletions(-) > > > > > > diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c > > > index 8fe7b5ee86..ea36247eb9 100644 > > > --- a/libavcodec/apedec.c > > > +++ b/libavcodec/apedec.c > > > @@ -575,14 +575,10 @@ static inline int ape_decode_value_3990(APEContext > > > *ctx, APERice *rice) > > > base = range_decode_culfreq(ctx, pivot); > > > range_decode_update(ctx, 1, base); > > > } else { > > > - int base_hi = pivot, base_lo; > > > - int bbits = 0; > > > + int base_hi, base_lo; > > > + int bbits = 16 - ff_clz(pivot); > > > > This assumes unsigned is always 32bit, no? > > ksum is 32 bit, from which pivot is derived. > > Should I use explicitly uint32_t type instead? > Where is unsigned not 32bit?
I don't think uint32_t would help, as ff_clz() can expand to a compiler builtin. What I'm concerned about is the unstated assumption about sizeof(int/unsigned) == 4 spreading through the codebase. It's already present in plenty of places, so I certainly don't intend to block your patch over this. But we should consider explitly documenting this, and maybe testing in configure. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".