簡單的代碼，復(fù)雜的問題。
環(huán)境：VC6SP5,Win2kPro
int b = 10; //已經(jīng)賦值為有效數(shù)據(jù)
const char * str = "1234567890ABCDEF"; //已經(jīng)賦值為有效的字符串。
int a = (b - strlen(str) ) / 2;
經(jīng)過了這樣的計(jì)算，a的值究竟是多少？
結(jié)果當(dāng)然不是 (10-16)/2 的 -3，而是一個(gè)天文數(shù)字。。。。
a = 2147483645 或者，16進(jìn)制的 0x7ffffffd
真正的問題代碼只有一行，但是結(jié)果卻令人不快。
這里分析一下產(chǎn)生這個(gè)問題的原因：
一個(gè)隱含的問題是，strlen的返回值，類型是size_t，也就是unsigned int。這是個(gè)無符號(hào)類型。
當(dāng)unsigned int 和 int混合運(yùn)算的時(shí)候，編譯器會(huì)認(rèn)為，unsigned int的表達(dá)長度比較長，因而結(jié)果的類型是unsigned int。
所以 b - strlen(str) 的結(jié)果不是 -6，而是和-6具有相同內(nèi)存布局的unsigned int 值：0xfffffffa，也就是正的4294967290
如果這個(gè)數(shù)值直接賦值給int，會(huì)因?yàn)閮?nèi)存布局相同，而避免問題的產(chǎn)生－－問題存在，但是不產(chǎn)生不良效果。但是隨后的/2操作把問題徹底暴露出來了。。
/2操作可以認(rèn)為是一次移位，對(duì)于無符號(hào)類型，移位后高位補(bǔ)0，于是把原本有符號(hào)類型賴以利用的符號(hào)位清零了。。最終這個(gè)數(shù)值賦值給int類型的時(shí)候，結(jié)果就變成了前面提到的那個(gè)可怕的數(shù)值。。
有符號(hào)數(shù)字和無符號(hào)數(shù)字混合運(yùn)算的時(shí)候，存在一些默認(rèn)的轉(zhuǎn)換規(guī)則，符合這些規(guī)則的轉(zhuǎn)換，都不會(huì)引發(fā)編譯器警告或者錯(cuò)誤，因此這類問題是難以覺察的。但是，我們需要經(jīng)常使用的庫函數(shù)太多了，當(dāng)參與運(yùn)算的時(shí)候，為每個(gè)函數(shù)調(diào)用都指定一個(gè)固定類型的返回值，似乎是不可能的任務(wù)。因此如果你的程序中充滿各種不同類型的整型運(yùn)算，那么還是盡量小心一些吧。。。