Match existing type usage better.

webrtc/modules/audio_coding/codecs/cng/webrtc_cng.c

Index: webrtc/modules/audio_coding/codecs/cng/webrtc_cng.c
diff --git a/webrtc/modules/audio_coding/codecs/cng/webrtc_cng.c b/webrtc/modules/audio_coding/codecs/cng/webrtc_cng.c
index 9862f125371d025538f83a721668ab6e8b158e36..cb7aa4567d4f3f93978f4cb6ba76aad199588baa 100644
--- a/webrtc/modules/audio_coding/codecs/cng/webrtc_cng.c
+++ b/webrtc/modules/audio_coding/codecs/cng/webrtc_cng.c
@@ -370,7 +370,7 @@ int16_t WebRtcCng_Encode(CNG_enc_inst* cng_inst, int16_t* speech,
     }
     if ((i == 93) && (index == 0))
       index = 94;
-    SIDdata[0] = index;
+    SIDdata[0] = (uint8_t)index;

[kwiberg-webrtc, 2015/06/08 13:09:37]

Why is this sort of cast net useful? It has the advantage of communicating that
the author wanted to indicate that the value's type was too large (or similar),
but the compiler doesn't verify it, and with the cast also won't catch a bunch
of other mistakes. You can also no longer tell by looking at the program text
whether a cast is required or just decoration (since both classes are now
nonempty).

This argument is slightly weaker in C++, where casts aren't as powerful.

[Peter Kasting, 2015/06/08 20:44:28]

By "the compiler doesn't verify it", do you mean that you're concerned about
missing some sort of value-propagation-based warning that might happen today
about casting an out-of-range value?

If so, I don't believe the places I'm modifying really run this risk -- I don't
think the compiler is sophisticated enough to do compile-time analysis to
determine the complete range of possible values here and produce such warnings,
and we're not currently generating run-time range checks in such code either. 
So I don't think there's any loss of warning coverage.
Can you be more specific what mistakes adding this cast prevents catching?  If
you're concerned about the compiler catching downcasts from larger types --
that's precisely the warning I'm trying to enable, which found this to begin
with, and for which I manually inspected the code and verified that it's safe. 
Without adding these sorts of casts in the safe locations, we can't enable such
a warning, so we can't catch these at all.
Are you saying, you can't tell whether the cast is required in order to compile
cleanly?  The idea is to enable warnings such that this is, in fact, required in
order to compile cleanly.

[kwiberg-webrtc, 2015/06/09 00:48:12]

No, I meant that the compiler only verifies that the cast is legal,
not that it is needed, or that it is equivalent to the implicit cast
the compiler would have used had the explicit cast not been there.
The risks I'm worried about are largely the ones I mention above: that
the compiler doesn't verify that the cast is needed, or that it is
equivalent to the implicit cast the compiler would have used had the
explicit cast not been there. This means, for example, that you can
cast to a too-small type without the compiler complaining. I'm sure it
doesn't happen now, since you added the casts with the help of the
compiler, but a later refactoring could silently break things.
This objection is rendered somewhat moot since you do in fact have a
machine telling you where to insert casts (although I'd personally
classify these casts as "humoring the compiler" rather than
"required").

[Peter Kasting, 2015/06/09 01:18:14]

Right, so this would be two issues:

(1) Adding an explicit cast to type T when the source is already of type T
(2) Casting to type T when the destination is actually of type U

For (2), at least, if T is larger than U, the compiler can still catch this.  If
it's smaller, though, it won't.

I wonder if we could get clang warnings about both these things.  (1) should
just be deleted, while (2) suggests the code may have a bug, possibly due to
refactoring.

[kwiberg-webrtc, 2015/06/09 01:28:26]

Those sound very useful to me. Not sure how much of a problem there would be
with false positives, though.

 
     /* Quantize coefficients with tweak for WebRtc implementation of RFC3389. */
     if (inst->enc_nrOfCoefs == WEBRTC_CNG_MAX_LPC_ORDER) {