IAR MSP430 bug 危險的取反操作

今天卻一下子發(fā)現好幾個(gè)bug。。。。

第一個(gè)bug：

語(yǔ)句if ((packnum == UartA0Waitchar()) && (packnum ==(~UartA0Waitchar()) ) )被編譯器直接編譯沒(méi)了，編譯器認為這句話(huà)永遠不會(huì )成立，而實(shí)際上UartA0Waitchar()是個(gè)串口取字符函數，每次取回來(lái)的結果都不是一樣的，這個(gè)if完全有可能成立。剛開(kāi)始認為只要將編譯器的優(yōu)化取消即可，可是在將option->c/c++ compile ->Optimizations->level的值改為none后，if語(yǔ)句仍舊沒(méi)了。。。。

第二個(gè)bug：

定義了packnum/rcvpacknum1/rcvpacknum2三個(gè)變量，都是unsigned char類(lèi)型的。在實(shí)際執行過(guò)程中，可以查看到packnum存儲于R6中，值為0x0001，rcvpacknum1存儲于R7中，值為0x0001，rcvpacknum2存儲于R8中，值為0x00FE。

1.語(yǔ)句packnum == rcvpacknum1,等式成立；

2.語(yǔ)句packnum == ~rcvpacknum2，等式不成立；

3.語(yǔ)句packnum == (unsigned char) ~rcvpacknum2，等式成立；

等式2之所以不成立，是以為0x00fe取反后位0xff01，所以和packnum不相等。問(wèn)題出現了，我在定義這3個(gè)變量的時(shí)候，已經(jīng)明確聲明了變量類(lèi)型為unsigned char，為什么在實(shí)際比較的時(shí)候去比較16bit的寬度呢?。。?！
對于第二個(gè)bug，有下圖可以作證。