IAR MSP430 bug 危險(xiǎn)的取反操作

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

第一個(gè)bug：

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

第二個(gè)bug：

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

1.語句packnum == rcvpacknum1,等式成立；

2.語句packnum == ~rcvpacknum2，等式不成立；

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

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