[FFmpeg-devel] [PATCH 001/244] Add a new channel layout API

[Michael Niedermayer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20191209/ecdd3189/attachment.sig>