不解釋,直接上圖,自己測試
網友評論：這不能算是一個 bug, 只是超出人們的預期而已。整數(shù)除法有著舍入方向的問題，向上舍入與向下舍入都不能說成是錯誤。
很多編譯器，特別是沒有高速硬件除法cpu上的編譯器，會對 /2, /4, /8等等優(yōu)化，用移位來代替真正 ...
highgear 發(fā)表于 2011-9-26 21:15
沒開優(yōu)化也用移位，實在是不應該。。。。
網友評論：樓上，C的標準并沒有規(guī)定負整數(shù)除法的方向，實際上，早期的標準聲明負整數(shù)除法的舍入方向取決與cpu 以及編譯器。
因此，-5/4的結果為-1還是-2都不能算是一個錯誤，都是正確的，只要遵循了同一個方向的舍入。很多的c/c++書中特地對負整數(shù)除法的舍入方向提出了告誡。
網友評論：highgear老師解釋的透徹，學習了
網友評論：
keil 這確實不能算是一個 bug, 只是超出人們的預期而已。
整數(shù)除法有著舍入方向的問題，向上舍入與向下舍入都不能說成是錯誤。
網友評論：樓上，C的標準并沒有規(guī)定負整數(shù)除法的方向，實際上，早期的標準聲明負整數(shù)除法的舍入方向取決與cpu 以及編譯器。
因此，-5/4的結果為-1還是-2都不能算是一個錯誤，都是正確的，只要遵循了同一個方向的舍入。很多的c/ ...
highgear 發(fā)表于 2011-9-27 02:10
還不能算BUG算什么？我看你都沒仔細看大家的討論！是不是BUG關鍵在于：
| -5/4 | > | -5/3
網友評論：|上面大家有很多人認為這不是個BUG,也許有些道理
但請大家再去測試以下的代碼,
signed char x,y,z,a;
z = -5;
a = 4;
x = z/a;
y = z%a;
如果按以上有些理論,至少KEIL應該結果一樣
但真正的結果呢
網友評論：還有
試試
signed char x;
x = -5/4
網友評論：上面大家有很多人認為這不是個BUG,也許有些道理
但請大家再去測試以下的代碼,
signed char x,y,z,a;
z = -5;
a = 4;
x = z/a;
y = z%a;
如果按以上有些理論,至少KEIL應該結果一樣
但真正的結果呢 ...
ayb_ice 發(fā)表于 2011-9-27 08:14
只因為 z/a用的是庫函數(shù)，而不是移位運算！
如果庫函數(shù)也遵循同樣的舍入方向也沒問題，看到這個問題我的第一想法就是:是不是舍入方向問題？
所以才做了這些測試，關鍵就是 z(-5)/4 != z(-5)/3!
網友評論：樓上，C的標準并沒有規(guī)定負整數(shù)除法的方向，實際上，早期的標準聲明負整數(shù)除法的舍入方向取決與cpu 以及編譯器。
因此，-5/4的結果為-1還是-2都不能算是一個錯誤，都是正確的，只要遵循了同一個方向的舍入。很多的c/ ...
highgear 發(fā)表于 2011-9-27 02:10
我知道的是，C和C++向0方向舍入。
沒啥好爭的了，大家都清楚，是優(yōu)化導致C51編譯器采用了移位方法進行運算，導致了“非預期的結果”。這本身就是不應該的事情。而同樣的ARM編譯器卻沒有類似情況。大家使用int型去試試就知道了。
同時這也告戒我們，編寫程序要嚴謹，為避免出現(xiàn)可能的“非預期結果”，可以參照13樓的方法，杜絕摸棱兩可的不同結果，這才是編程的思想。
網友評論：還有
試試
signed char x;
x = -5/4
ayb_ice 發(fā)表于 2011-9-27 08:21
x = -5/4就不關keil事了，這個時候（-5/4）是PC機
計算的。
網友評論：也許真的不是BUG，只是超出了人們的預期而已，設計的人沒想到會有人直接把立即數(shù)寫到程序里；
就好像設計火車的人們根本沒預期天上會下雨打雷；是在是屬于使用錯誤；
網友評論：也許真的不是BUG，只是超出了人們的預期而已，設計的人沒想到會有人直接把立即數(shù)寫到程序里；
就好像設計火車的人們根本沒預期天上會下雨打雷；是在是屬于使用錯誤； ...
mcu5i51 發(fā)表于 2011-9-27 08:30
這個說法太牽強了，每個BUG都是超出設計者的預期的！
而且錯不在移位運算，假如庫函數(shù)用的也是同一個舍入方向那就不是BUG了!而偏偏它們用的是不同的舍入方向。
網友評論：BUG就是BUG
至少你KEIL C51應該保持一致
這個不是BUG,那另外的不一致的那個就是BUG
網友評論：也許真的不是BUG，只是超出了人們的預期而已，設計的人沒想到會有人直接把立即數(shù)寫到程序里；
就好像設計火車的人們根本沒預期天上會下雨打雷；是在是屬于使用錯誤； ...
mcu5i51 發(fā)表于 2011-9-27 08:30
開玩笑都是
下面的程序難道大家沒有用過
x/10
x%10
x/16
x%16
網友評論：t.jm:
這是優(yōu)化所產生的問題， y = x/4 與 y = x/a 的結果不同并不出乎意料。很多編譯器對 /2, /4, /8 等常數(shù)分母都是直接使用移位而不是除法，這也不是超出預期，反而是在預期之內。
對于分子分母都是變量，keil 中 -5/4 = -5/3 的結果都是-1.
網友評論：t.jm:
這是優(yōu)化所產生的問題， y = x/4 與 y = x/a 的結果不同并不出乎意料。很多編譯器對 /2, /4, /8 等常數(shù)分母都是直接使用移位而不是除法，這也不是超出預期，反而是在預期之內。
對于分子分母都是變量，keil 中 ...
highgear 發(fā)表于 2011-9-27 09:00
你說的也很對,但其它編譯器都是正確的,一致的,我至少試過4~5種不同的編譯器
優(yōu)化都不能保證結果正確,還談什么優(yōu)化,還是BUG
網友評論：呵呵，這么說吧，我在不同的編譯器下做過大量的數(shù)**算，除了vc++, 嵌入式中基本上都是使用整數(shù)運算，但我從不使用 /2, /4, /8等等，都是直接使用 >>1, >>2, >>3等，了解編譯器的行為是一個嵌入式程序員基本功課。
網友評論：t.jm:
這是優(yōu)化所產生的問題， y = x/4 與 y = x/a 的結果不同并不出乎意料。很多編譯器對 /2, /4, /8 等常數(shù)分母都是直接使用移位而不是除法，這也不是超出預期，反而是在預期之內。
對于分子分母都是變量，keil 中 ...
highgear 發(fā)表于 2011-9-27 09:00
暈！這根本不關優(yōu)化的事，優(yōu)化也是好的行為，肯定的！
只要它能保證：（-5/4） == （-5/3），它就不是BUG了，也就沒有什么危害至多是計算精度問題，
然而：（-5/4） != （-5/3）,而且|（-5/4）| > |（-5/3）|這才是致命的危害！
再討論這個問題前，舍入問題我是有考慮的，你應該多多考慮：
（-5/4） != （-5/3）,而且|（-5/4）| > |（-5/3）|的嚴重性！
網友評論：ayb_ice: 你不能說“優(yōu)化都不能保證結果正確”， 只能說結果不是你所預期的。因為，-5/4為-1或是 -2 都是正確的。
網友評論：呵呵，這么說吧，我在不同的編譯器下做過大量的數(shù)**算，除了vc++, 嵌入式中基本上都是使用整數(shù)運算，但我從不使用 /2, /4, /8等等，都是直接使用 >>1, >>2, >>3等，了解編譯器的行為是一個嵌入式程序員基本功課。 ...
highgear 發(fā)表于 2011-9-27 09:12
恕我直言，你這點技巧什么都不算，甚至你都搞錯方向了，
是除法（/)能代替移位(>>),而不是移位(>>)代替除法（/)，我要/3怎么辦？
網友評論：ayb_ice: 你不能說“優(yōu)化都不能保證結果正確”， 只能說結果不是你所預期的。因為，-5/4為-1或是 -2 都是正確的。
highgear 發(fā)表于 2011-9-27 09:18
如果只考慮結果這個確實沒有錯,但起碼必須保持一致吧
不要一會=-1,一會又等于-2吧
從數(shù)學上講難道
x = -5/4;
和
y = -5;
z = 4
x = y/z;
是不一樣的
網友評論：改成int型就對了。
網友評論：t.jm: 其實全整數(shù)運算需要很多技巧，而且必須對cpu以及編譯器有足夠的了解，否則就會出現(xiàn)什么 “詭異”，“bug"之類的困惑。
除數(shù)是變量時，我想不會有問題，因為編譯器一般會使用除法器。對于除數(shù)是常數(shù)，那么"什么都不算的技巧"相當有用，坦白的說，除了vc++, 我?guī)缀醪挥贸?shù)除法，而是用乘法代替，例如: x /3 可為 x * (65536/3) >> 16 （cpu 具有16x16的乘法器） 或是 x * (256/3) >> 8。
再解釋一次：
樓主的情況僅僅是在除數(shù)是常數(shù)2，4， 8 等而且被除數(shù)為負值的情況下出現(xiàn)，是因為編譯器優(yōu)化使用了因為而不是使用除法器，這其實是有經驗的程序員所預期的。同時，除非不關注效率，最好不要直接使用常數(shù)除法，可以使用 >> 以及乘法代替。
網友評論：是因為編譯器優(yōu)化使用了移位而不是除法器
網友評論：e...很少用到除法，2，4，8這些一般都是移位代替，效率要高一些。
網友評論：不懂,求高手解答
網友評論：t.jm: 其實全整數(shù)運算需要很多技巧，而且必須對cpu以及編譯器有足夠的了解，否則就會出現(xiàn)什么 “詭異”，“bug"之類的困惑。
除數(shù)是變量時，我想不會有問題，因為編譯器一般會使用除法器。對于除數(shù)是常數(shù)，那么"什么 ...
highgear 發(fā)表于 2011-9-27 21:02
問題的焦點就不同的寫法要結果一致,程序怎么寫,只要合法就行了,何況這是常見寫法呢
網友評論：t.jm: 其實全整數(shù)運算需要很多技巧，而且必須對cpu以及編譯器有足夠的了解，否則就會出現(xiàn)什么 “詭異”，“bug"之類的困惑。
除數(shù)是變量時，我想不會有問題，因為編譯器一般會使用除法器。對于除數(shù)是常數(shù)，那么"什么 ...
highgear 發(fā)表于 2011-9-27 21:02
我只能告訴你，你剛才說的這些“技巧”我全知道！
用>>代替除法，你以為（-5）/ 4!= (-5) >> 2 ???
你說的這個“技巧”根本就無助與解決這個BUG！不管你是用/還是用>>：
1）|（-5）/ 4 | > |(-5) / 3|;
2）|（-5）>> 2 | > |(-5) / 3|; 你會選這種結構吧（>>）？？
網友評論：t.jm: 其實爭論這個情況是不是個 bug, 沒有什么結果，因為判據(jù)不一致。對于我來說，我預期 x/4 為 x >> 2, 所以我不會認為 x/4 = -2是一個 bug，這也是我即使在 vc++下也不使用 x/4而是用 x>>2 的原因，因為vc++下的 x/4 會+3做調整，即 x/4底層為 （x+（x<0？3:0))>>2, 這會導致vc++ 下的算法程序直接移植后，結果可能不一致。
是不是個 bug, 痣者見痣，忍者見忍。
網友評論：t.jm: 其實爭論這個情況是不是個 bug, 沒有什么結果，因為判據(jù)不一致。對于我來說，我預期 x/4 為 x >> 2, 所以我不會認為 x/4 = -2是一個 bug，這也是我即使在 vc++下也不使用 x/4而是用 x>>2 的原因，因為vc++下的 ...
highgear 發(fā)表于 2011-9-28 09:59
你這樣的考慮還怎么： 痣者見痣，忍者見忍???
/,>>這些技巧在IAR面前都是浮云，IAR會做出正確而高效的優(yōu)化！
1）是不是BUG | -5 / 4| > |-5>>2|是鐵證！
2）是不是優(yōu)化，明顯地IAR的對比可以讓keil無地自容，兩個常數(shù)的運算居然沒有讓編譯器去完成還談什么優(yōu)化？
x = -5/4,應該直接優(yōu)化為 x = -1,
x = -5 >> 2 應該直接優(yōu)化為 x = -2!
網友評論：=-1,=-2確實都是正確的,因為C語言也是這樣規(guī)定的
但同一個版本的編譯器,不同的寫法,不同的結果這就不對了,因為不同的寫法本質是一樣的,根本不可能有其它的解釋
網友評論：=-1,=-2確實都是正確的,因為C語言也是這樣規(guī)定的
但同一個版本的編譯器,不同的寫法,不同的結果這就不對了,因為不同的寫法本質是一樣的,根本不可能有其它的解釋 ...
ayb_ice 發(fā)表于 2011-9-28 10:36
這個意思我早就表達了，
不管編譯器（keil.IAR)它采用什么策略去計算 -5/4，-5/3,一致性它必須要遵守的，舍入的方向必須一致，-5/4 = -2，或=-1無非是精度問題，這不致命！
|-5/4|>|-5/3|在同一個軟件中出現(xiàn)就是致命問題，藐視它，它就有可能是導致動車追尾的因素！
網友評論：IAR 我不知道，樓主的情況是不是bug尚有爭議；但 t.jm 說keil“兩個常數(shù)的運算居然沒有讓編譯器去完成還談什么優(yōu)化”，顯然是臆想。
網友評論：這個應該是在意料之中的事情，編譯器為了高效使用了 RLC 指令
這個經常導致算法不穩(wěn)定，有時甚至無法收斂.
網友評論：其實不是keil的錯。
以8086為例：你用DIV，還是IDIV，同樣的 -5/4，將會得到2個結果。關鍵是。2個結果都是對的： 注意商不一樣，余數(shù)就不一樣！
-5/4= -1……-1；
-5/4= -2……+3；
LZ的題目應寫成下面，告訴編譯器你要進行有符號除法而不是無符號除法運算：
main(void )
{
signedcharx,y,z;
z=-5;;
x=z/(signed)4; // 或者x=(signed) z/4;
y=z%4;
while(1);
}
網友評論：
上面帶符號除法運算，C51調用專用除法庫函數(shù)，余數(shù)在B。
無符號除法才用邏輯移位。否則符號位怎么處理？
網友評論：常數(shù)/非int型變量前加強制轉換：(int)
網友評論：我也有碰到過哎
網友評論：搞編程的對BUG到底有沒有清晰的定義？
我問你們：哪個BUG不是超出設計者預期？
又比如windows的BUG會被病毒設計者利用，你不利用它這個BUG又有什么傷害？你不利用別人會利用啊！
你不做/4運算別人有可能會用啊！
依次展開想象，今天你們用的有效計算方法，哪天就可能失效的，比如一再被大家提到的：
int/4,這只取決于，keil有沒有興趣把它優(yōu)化為移位運算！你們所附加的強制類型轉換會不會出錯也取決于keil
會不會自作聰明的優(yōu)化！
網友評論：在9.03上實驗了一下，的確如樓主所說，我們可以認為這是一個bug。
問題的根源就在于對于字符型變量除以2的整數(shù)冪時，編譯器會按照右移位的方式進行“快捷”運算，這樣做的后果便是對有符號數(shù)的舍入方向將不一致。
而取余運算、以及非單字節(jié)運算，編譯器都會調用庫函數(shù)，因此不會存在這種問題。
樓主不介意的話，我去把這個bug向官方反饋一下，免得今后害人。
網友評論：其實不是keil的錯。
以8086為例：你用DIV，還是IDIV，同樣的 -5/4，將會得到2個結果。關鍵是。2個結果都是對的： 注意商不一樣，余數(shù)就不一樣！
-5/4= -1……-1；
-5/4= -2……+3；
LZ的題目應寫成下面，告訴編譯 ...
劉前輩 發(fā)表于 2011-9-28 18:44
改成
"x=z/(signed)4"
實際是等于
"x=z/(signed int)4"
這時結果當然對了,一個是char型除法了,一個是整型除法了
真正的BUG就是在此了
-5和4沒有超出signed char的數(shù)據(jù)表示范圍,用char除法和int除法應該結果是一樣的才對
網友評論：在9.03上實驗了一下，的確如樓主所說，我們可以認為這是一個bug。
問題的根源就在于對于字符型變量除以2的整數(shù)冪時，編譯器會按照右移位的方式進行“快捷”運算，這樣做的后果便是對有符號數(shù)的舍入方向將不一致。
而 ...
ejack 發(fā)表于 2011-9-29 08:14
這才是一個好人啊！
問題的根源大家都是知道的，就是移位代替真正除法產生的舍入方向不一致問題！
假如庫函數(shù)的除法移位除法也是同一個舍入方向就沒問題了，也就不再依賴于所謂的技巧:"/ >> int ..."
但是居然大多數(shù)電工都表現(xiàn)出：這就不是BUG，就如動車相撞、地鐵相撞關我們電工屁事啊！！
網友評論：如果用移位代替有信號除法的話
結果至少是-1(被除數(shù)是負數(shù)的情況下)
網友評論：如果一個軟件造成了飛機爆炸，動車相撞的事故，那一定是 人 造成的，而不是編譯器。把事故歸咎于編譯器與鐵道部的可恥言論沒有什么區(qū)別。
網友評論：記得有位編程大佬說“優(yōu)化會產生不確定性”，看來有一定道理。
網友評論：以前有個程序是在很老的版本下編譯的，十幾年來一直都很穩(wěn)定，后來用最新版本又重新編譯了，結果就不穩(wěn)定了，開始是以為干擾問題，后來發(fā)現(xiàn)是優(yōu)化問題，新版本比老版本優(yōu)化不一樣，過分智能了。
網友評論：如果一個軟件造成了飛機爆炸，動車相撞的事故，那一定是 人 造成的，而不是編譯器。把事故歸咎于編譯器與鐵道部的可恥言論沒有什么區(qū)別。
highgear 發(fā)表于 2011-9-29 08:57
這個話有些武斷了
編譯器也是人做的,有BUG不稀奇,如果是商業(yè)編譯器,花了錢,是可以向廠家索賠的,這個沒有問題的
測試的人也不能保證完全測試OK,當你知道有隱患的話,問題好解決,關鍵有些隱患不太明顯,很難知道,當年INTEL的CPU有浮點運算錯誤,那你能說是微軟不行,用戶不行嗎
網友評論：以前有個程序是在很老的版本下編譯的，十幾年來一直都很穩(wěn)定，后來用最新版本又重新編譯了，結果就不穩(wěn)定了，開始是以為干擾問題，后來發(fā)現(xiàn)是優(yōu)化問題，新版本比老版本優(yōu)化不一樣，過分智能了。 ...
yhn1973 發(fā)表于 2011-9-29 09:14
所以我說了，今天int/4是正確的，不代表將來也正確，發(fā)現(xiàn)BUG了不抓被咬一口就晚了！
而人啊，似乎是被咬了一口的BUG才算BUG，沒咬過自己的不算！
網友評論：呵呵~~~
LS各位高手爭論異常激勵，有從C定義出發(fā)，認定這不能算是一個 bug, 只是超出人們的預期而已。
也有的人一口咬定這是一個bug,不過，不管怎么樣，LS的盆友們都想出了名種方法，希望結果能得到人們預期的那樣，但大多數(shù)盆友一般是將 /2或 /4轉換成 int類型，以避開 keil對 char型變量的優(yōu)化。
但是，將數(shù)據(jù)類型轉換成 int類型，運算太費時間，程序也比原 char型運算長許多，并不理想~~~
這里向大家推薦兩種常用方法，概避開了 keil對 /2或 /4char型變量的優(yōu)化，又使用char型運算，運算時間僅比原來理想中增加幾個時鐘周期，程序也僅比原來增加幾個字節(jié)，屬于比較理想的打補丁，供大家參考~~~
方法1(ayb_ice推薦，特點是直觀，但費時和占程序容量略多幾個字節(jié)）
signed char x,z,a;
z = -5;
a = 4;
x = z/a;
方法2(俺推薦，用負數(shù)做除數(shù)，再對結果求補，特點是速度更快，費時更少，僅增加程序容量2個字節(jié)）
signed char x,z;
z = -5;
x = -z/-4; // 或寫成 x = -(z/-4);效果一樣。
網友評論：贊成樓主，確實是個BUG！因為z/3,z/5 都能正確調用CDIV （不是IDIV）字節(jié)除法庫函數(shù)。
想了個辦法，終于把z/4 能避開編譯器移位BUG而用CDIV 函數(shù)計算了。
#include<REG52.h>
#include<math.h>
main(void )
{
signedchar x, y,z;
z=-5;
x=z/cabs(4);
y=z%4;
while(1);
}
這里有個基本概念： 2個二進制數(shù)的除法A/B，首先要符號位一致！然后才能進行運算。
所以一個負數(shù)z/+4,根本不可能用移位>>2來得到正確值；除非先把z轉換為正整數(shù)cabs(z)。
x=cabs(z)/4; 也是對的。
網友評論：無論C?SCDIV （char 字節(jié)除法庫函數(shù)）還是 C?SIDIV （int 除法庫函數(shù)），首先都要將除數(shù)、被除數(shù)轉化為符號一致的2個數(shù)。
網友評論：74#
方法2(俺推薦，用負數(shù)做除數(shù)，再對結果求補，特點是速度更快，費時更少，僅增加程序容量2個字節(jié)）
signed char x,z;
z = -5;
x = -z/-4; // 或寫成 x = -(z/-4);效果一樣。
千萬別推薦方法2。x = -z/-4;和x = -(z/-4); 結果不一樣！無論是手算還是程序算：
1、x = -z/-4 = 5 /-4 = -1 余 +1 ;
2、x = -(z/-4)= - ( 5 / 4) = -1余 -1 ;
、、
網友評論：這是向上舍入，還是向下舍入的問題， 與 c 語言無關。除法與算數(shù)移位的舍入方向不同，所以負數(shù)會產生不同結果。在數(shù)字信號處理中，對于算數(shù)移位操作通常需要加 0.5 補償， 即 ：
(x + (1<<(N-1))) >> N
這樣可以防止算數(shù)移位向下舍入帶來的誤差。例如： -1 /32768，結果為 0， 但 -1 >> 15 = 0xFFFF>> 15 = 0xFFFF = -1, 即有一個相當大的舍入誤差。對微弱信號處理時，可以明顯地看到加 0.5 補償后的效果。
網友評論：Keil 論壇上也有類似的討論：
http://www.keil.com/forum/19617/
以及這一個：
http://www.keil.com/forum/14461/
No, it's not a bug at all.
If you get out your copy of K&R and look at the chapter about arithmetic operators, it say that the direction of truncation for the division operator is machine-dependent for negative operands.
This means that the result of (-1 / 2) can be 0 or -1 depending on the hardware and/or the compiler. Neither of the results would be considered an error of the compiler.
If you need a certain direction when truncating the result of dividing a negative number, you will have to do so by hand.
As already noted, the compiler can do whatever it likes for the division. The library function is well-defined - but there is no requirement for it to be the same!
網友評論：Keil 論壇上也有類似的討論：
的確編譯器擁有選擇向零舍入或離零舍入的自由，但至少自己應該統(tǒng)一方向。
一會兒這樣、一會兒那樣，你能認為這種設計不存在問題嗎？你能說這不是一個bug嗎？除非Keil公開聲明：“大家別用有符號整型做除法，俺不保證后果……”
網友評論：
79# 那兩個帖子也能算討論？就幾個人說了幾句話，正反1:1，說的都不到這里的1%，另一個明顯是我們這里的ejack去報告的！
已經說過是不是BUG不是那么判地，精度問題可以接受，邏輯錯誤問題是不能接受的！
假如：
signed char ad1,ad2, x,y;
ad1 = -5;
ad2 = -5;
x = ad1/4;
y = ad2/3;
if(x > y){
....
}
else{
....
}
網友評論：作為技術人員應具備嚴謹?shù)木窈屠硇缘膽B(tài)度。對于負整數(shù)除法，我比較了 c89 與 c99 標準，c89 并未規(guī)定舍入方向，而 c99 規(guī)定了 truncate to zero. 如果 keil c 聲稱遵循 c99, 則向上舍入是一個bug, 否則，就不能說這是一個bug, 不論是否合乎人們的預期，也不宜憑個人感覺或是好惡。雖然可以指責keil違背一致性原則，而違背一致性原則有時比 bug 還惡劣。
Keil C 遵從 C90:
Keil C compilers are based on C90. We added some language extensions as practical concessions to the architectural peculiarities of the microcontrollers we support and the needs of embedded systems programmers.
t.jm 樓上的例子在 c89 之類的編譯器下沒有實際意義，因為編譯器不保證負整數(shù)除法的舍入方向，這應是程序員自己來保證舍入。t.jm 堅持是一個bug, 那么請指出違背了標準中的哪一條原則。
網友評論：可以認為,不一致就是BUG
我還認為是嚴重BUG
網友評論：作為技術人員應具備嚴謹?shù)木窈屠硇缘膽B(tài)度。對于負整數(shù)除法，我比較了 c89 與 c99 標準，c89 并未規(guī)定舍入方向，而 c99 規(guī)定了 truncate to zero. 如果 keil c 聲稱遵循 c99, 則向上舍入是一個bug, 否則，就不能說 ...
highgear 發(fā)表于 2011-9-30 08:56
你還真能據(jù)“理”力辯呢！！
“雖然可以指責keil違背一致性原則，而違背一致性原則有時比 bug 還惡劣。”
你意思是說就像一個IC，你的使用超出我的承認書范圍，出現(xiàn)任何問題我一概不負責？？？
這我不茍同！！！！
其它編譯器又是以什么為標準？IAR8051,FSL CWS08,STVD,KEIL ARM,SDCC 51...怎么不見別人犯錯？
網友評論：ayb_ice: 那么就拿出確實的證據(jù)出來，而不是“我認為”。 不一致性在 c#, java 語言中也都存在，例如java 中著名的字符串 == 比較問題，也不被認為是 "bug"。
t.jm: 首先， -5/4 = -2 不是錯誤。其次，如果ic的承認書范圍沒有違背法令或是行業(yè)標準，那么用戶是應該為不當使用而負責。至于其他編譯器，并不是標準，無從參照。
