C unsigned modulusによってコンパイラの警告が発生する

Question

MC9S12C32マイクロコントローラ用の埋め込みCコードでは、静的サイズのバイト配列とキューの前後に2つの "ポインタ"を使用して循環キュー（別名循環バッファ）実際にはキューの配列のインデックスにすぎません。 trearが後部要素の実際の指標であるが、tfrontは、前部要素（コースの16を法とする被験者）の実際の屈折率よりも小さいものであること

// call unsigned chars bytes 
typedef unsigned char byte; 
byte trear = 0; // SCI transmit display buffer IN index 
byte tfront = 0; // SCI transmit display buffer OUT index 
byte tsize = 16; // size of transmit buffer 
byte tbuf[16]= {0};// SCI transmit display buffer 

注意。だから私のバッファが「こんにちは」含まれている場合（空スロットがガベージ値である）、例えば、それは次のようになります。

：それはキューからバイトを削除する時が来たとき

_________________________________ 
| | |h|e|l|l|o| | | | | | | | | | 
^  ^
front  rear 

、私はこれを行います

// increment front index 
tfront++; 
// wrap front index if it exceeded bounds 
tfront %= tsize;       // (A) 
// get character to transmit 
byte outputChar = tbuf[tfront]; 

これはすべて問題なく動作します。少なくとも、私のプログラムではこのフラグメントに関するバグはありませんでした。私はこのプログラムをコンパイルするときしかし、私のコンパイラがラインについて私に警告文句、上記の断片で(A)をマーク：

警告：C2705：データ

main.cのライン損失の可能性402

を

行402は行（A）です。私はgccなどを使用していないことに注意してください。私はFreescaleのCodeWarrior IDEでコンパイルしています。これは、時には他にも幾分不思議な警告を与えています。警告を取り除くための試みで、私は、上記のようフラグメントを書き直し：

// increment front index mod tsize 
tfront = (tfront + 1 >= tsize) ? 0 : tfront + 1;  // (B) 
// get character to transmit 
byte outputChar = tbuf[tfront]; 

しかし、私のコンパイラは、まだ、ライン(B)については、この時間を同じ警告を発します。コンパイラが、文の中で(tfront + 1 >= tsize)、tfrontが実行前に255であり、オーバーフローしている可能性があります。もちろん、私はこれが起こらないことを知っていますが、私のコンパイラはしません。

この場合、なぜ(A)という行が問題になったのですか？基本的に、私はコンパイラが何を不幸にしているか知りたい。

---

私の質問を入力して以来、私は、プリプロセッサの定義（すなわち、#define TSIZE 16）に変数の型からtsizeを変更することによってそれを解決してきました。私の質問はまだ立っている。

---

いくつかの関連質問：
unsigned overflow with modulus operator in C
modulus operator with unsigned chars

Answer 1

コンパイラの警告の可能性が高いので、Cでのプロモーションルールのtfront = tfront % tsize;に相当しtfront %= tsize;、で表現tfront % tsizeは（持っているという事実から来ています*）タイプint。

代わりにtfront = (byte)(tfront % tsize);を書き込むと、コンパイラがサイレントになることがあります。

あり心配する特別な理由はありません、そして、あなたのコンパイラは確かに奇妙な警告を発する：表現tfront % tsizeは技術的理由は、それが計算されている方法のbyteにその値が、すべてのフィットをintを入力しているが。値がすべてbyteに収まらない場合でも、ラップアラウンドの動作は、符号なし整数型のC標準によって保証されています（目的に合わせてこのラップアラウンド動作を使用することが正当化されます）。

（*）あなたのコンパイルのプラットフォーム上でintは、それがタイプunsigned intであろうと、あなたはおそらく、警告は表示されません。その場合にはunsigned charが取ることができるすべての値を含めることはできません場合を除きます。

Answer 2

この警告は、すべてのCodewarriorコンパイラの既知のバグです。データの警告の可能性のある喪失は、一貫性がなく、バグがあります。暗黙的なタイプのプロモーションのリスクがあるため警告することもありますが、そうでない場合もあります。 this discussionを参照してください。私はこれがS12CのCW（少なくともバージョン5.1までは私が使用しているもの）にも当てはまることを確認できます。

この警告を無効にすることはできますが、誤った警告とともに危険なコードが見つかることがあるため、この警告は推奨しません。あなたの特定のケースでは、警告は正しいです。

明示的なキャストなしで小さな整数型の演算をしています。そのようなコードは危険であり、隠されたバグを含んでいる可能性があります。なぜなら、Cは小さな整数を符号付き整数に昇格させるからです。明示的なキャストを強制するMISRA-Cのようなコーディング標準がここで助けになっていました。

さらに、？：演算子は、それがどのように動作するか分からない限り危険です。 2番目と3番目のオペランドのバランスをとっており、おそらく期待していなかったでしょう。

Iゆえにコードを変更することを示唆している： `tsize`が2のべき乗であることを保証することができれば、ビットマスクを使用する方が効率的であり、そしてそれはまたきちんと避けること

tfront = (byte)(tfront % tsize); 
... 

if((byte)(tfront +1) >= tsize) 
{ 
    tfront = 0; 
} 
else 
{ 
    tfront++; 
}