On Mon, Dec 09, 2019 at 12:36:11AM +0100, Nicolas George wrote:
> Michael Niedermayer (12019-12-09):
> > One problem with unsigned is that in expressions you cannot have negative
> > values, nor can you compare to negative values without casting to signed.
> > That has some risk for producing unexpected behavior bugs
> >
> > for example
> > if (ch >= s->nb_channels) {
> > ...
> > } else if (ch < 0)
> > ...
> >
> > would not work as expected
>
> I do not see it as a problem, I see it as exactly what we want. If a
> value cannot meaningfully be negative, there is no sense in wasting time
> and code allowing it to be negative and then testing it.
>
> In the above code, ch should be unsigned too. Or, if it has a good
> reason to be signed (negative values meaning something else?), test them
> first.mixing unsigned and signed int of course works if one is aware of * what is signed, what is unsigned * exact semantics of expressions mixing them * does not miss any corner cases OTOH if everything is signed, then the developer does not need to worry about these things, and its easier to remember "all is signed int" vs. "these specific fields are unsigned" What i meant really is "Its easier to maintain code that is all int, instead of code mixing signed and unsigned int" Sometimes we need unsigned and thats fine, i think though when we dont "need" it, its better to use plain int. Just my oppinion, not objecting to anything Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri
signature.asc
Description: PGP signature
_______________________________________________ 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".
