Il modulo C senza segno causa il warning del compilatore

Question

In alcuni codici C incorporati per il microcontrollore MC9S12C32, ho una coda circolare (nota anche come buffer circolare) implementata con un array di byte di dimensioni statiche e due "puntatori" per la parte anteriore e posteriore della coda, che sono in realtà solo indici per l'array della coda.

// 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 

noti che trear è l'indice effettivo dell'elemento posteriore, ma tfront è uno inferiore indice effettivo dell'elemento anteriore (soggetto a con modulo 16 naturalmente). Così, per esempio, se il mio tampone conteneva "ciao", che potrebbe assomigliare a questo (dove gli slot vuoto sono i valori della spazzatura):

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

Quando è il momento di rimuovere un byte dalla coda, faccio questo:

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

Questo funziona perfettamente - almeno, il mio programma non ha mostrato bug relativi a questo frammento. Tuttavia, quando ho compilare questo programma, il mio compilatore mi mette in guardia circa la linea tracciata (A) nel frammento di cui sopra, lamentandosi:

Attenzione: C2705: possibile perdita di dati

linea main.c 402

La riga 402 è la linea (A). Devo notare che non sto usando gcc o simili; Sto compilando l'IDE CodeWarrior di Freescale, che a volte mi ha dato altri avvertimenti in qualche modo mistificanti. Nel tentativo di sbarazzarsi di avvertimento, ho riscritto il frammento di cui sopra come:

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

Tuttavia, la mia compilatore emette sempre lo stesso avvertimento, questa volta sulla linea (B). Forse il compilatore mi sta dicendo che nella dichiarazione (tfront + 1 >= tsize), tfront potrebbe essere 255 prima dell'esecuzione e overflow. Certo, so che questo non accadrà, ma il mio compilatore no.

Se questo è il caso, perché la linea (A) è stata un problema? Fondamentalmente, mi piacerebbe sapere di cosa sia infelice il compilatore.

---

Dal momento che digitando la mia domanda, ho risolto cambiando tsize da un tipo di variabile a una definizione di preprocessore (vale a dire, #define TSIZE 16). La mia domanda è ancora valida, però.

---

Alcune questioni connesse:
unsigned overflow with modulus operator in C
modulus operator with unsigned chars

Answer 1

L'avviso del compilatore probabilmente deriva dal fatto che nel tfront %= tsize;, che equivale a tfront = tfront % tsize;, a causa delle regole di promozione in C l'espressione tfront % tsize ha (*) digitare int.

È possibile disattivare il compilatore se si scrive tfront = (byte)(tfront % tsize);.

Non c'è un motivo particolare di preoccuparsi, e il compilatore emette strani avvertimenti anzi: anche se l'espressione tfront % tsize ha tecnicamente digitare int, i suoi valori tutti in forma in un byte a causa del modo in cui viene calcolato. Anche se i valori non si adattavano tutti in un byte, il comportamento di wrap-around è garantito dallo standard C per i tipi di numeri interi senza segno (in modo tale da giustificare l'utilizzo di questo comportamento di wrap-around).

(*) a meno che sulla vostra piattaforma compilation int non può contenere tutti i valori che un unsigned char può prendere, nel qual caso sarebbe di tipo unsigned int e probabilmente non vedrebbe l'avvertimento.

Answer 2

Questo particolare allarme è un bug noto in tutti i compilatori CodeWarrior. La possibile perdita di avviso dei dati è inconsistente e buggata. A volte avvisa perché c'è il rischio di promozioni di tipo implicito, a volte no. Vedi this discussion. Posso confermare che questo vale anche per CW per S12C (almeno per quanto riguarda la versione 5.1, che è quello che sto usando).

È possibile disattivare questo avviso, ma io non lo consiglio, dal momento che trovare il codice pericoloso a volte, insieme con i falsi allarmi. Come nel tuo caso specifico: l'avvertimento è corretto.

State facendo aritmetica su piccoli tipi interi, senza cast espliciti. Tale codice è pericoloso e potrebbe contenere bug nascosti, poiché C promuove piccoli numeri interi in toated. Uno standard di codifica come MISRA-C, che applica cast esplicito, avrebbe aiutato qui.

Inoltre, l'operatore?: Può anche essere pericoloso se non si sa come funziona. Bilancia il 2 ° e il 3 ° operando l'uno contro l'altro, quale forse non si aspettava.

Ritengo pertanto cambiare il codice a:

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

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