這個是今天在微信群里討論的一個問題，先看圖片

點擊查看大圖

代碼流程大概是這個樣子的

點擊查看大圖

查看 length 和 space1 的值，明顯看到 length 小于 space1 的值，即使是這樣小白都能搞懂流程的情況下，代碼還是跑到else里面區執行

調試查看數據

然后 我們就在群里討論，有的大神說這個是內存越界，也有大神說可能是人品有問題，也有大神說這個是因為寫代碼前沒有選好一個良辰吉日，反正大家想法都非常多，也非常古怪，這可能就是討論群存在的一個原因了。

經過不斷的驗證，發現這個問題是因為編譯器優化的問題。

如果在設置里面把優化選項去掉代碼就執行正確

編譯器對代碼優化

當然還有一個問題，就是如果我想開啟優化，畢竟代碼太大占用的存儲空間是很大的，如果能節省點空間是最好的了。所以就出現了一種，只針對某些代碼不優化的設置

像這樣

我們使用GCC編譯的時候，也是有可能因為代碼優化導致這樣的問題的，慶幸的是，GCC也有設置不進行優化的開關。

#使用GCC編譯器設置選擇性不優化某段代碼

#pragma?GCC?push_options #pragma?GCC?optimize?("O0") #pragma?GCC?pop_options

push 的意思是把當前的編譯優化選項壓棧，然后再設置當前的優化選項，之后再出棧，把之前壓棧的選項提取出來。

具體可以參考鏈接：

https://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Function-Specific-Option-Pragmas.html

鏈接里面還介紹了一些其他的用法，原文如下

5.52.12?Function?Specific?Option?Pragmas #pragma?GCC?target?("string"...) This?pragma?allows?you?to?set?target?specific?options?for?functions?defined?later?in?the?source?file.?One?or?more?strings?can?be?specified.?Each?function?that?is?defined?after?this?point?will?be?as?if?attribute((target("STRING")))?was?specified?for?that?function.?The?parenthesis?around?the?options?is?optional.?See?Function?Attributes,?for?more?information?about?the?target?attribute?and?the?attribute?syntax. The?`#pragma?GCC?target'?pragma?is?not?implemented?in?GCC?versions?earlier?than?4.4,?and?is?currently?only?implemented?for?the?386?and?x86_64?backends.#pragma?GCC?optimize?("string"...) This?pragma?allows?you?to?set?global?optimization?options?for?functions?defined?later?in?the?source?file.?One?or?more?strings?can?be?specified.?Each?function?that?is?defined?after?this?point?will?be?as?if?attribute((optimize("STRING")))?was?specified?for?that?function.?The?parenthesis?around?the?options?is?optional.?See?Function?Attributes,?for?more?information?about?the?optimize?attribute?and?the?attribute?syntax. The?`#pragma?GCC?optimize'?pragma?is?not?implemented?in?GCC?versions?earlier?than?4.4.#pragma?GCC?push_options #pragma?GCC?pop_options These?pragmas?maintain?a?stack?of?the?current?target?and?optimization?options.?It?is?intended?for?include?files?where?you?temporarily?want?to?switch?to?using?a?different?`#pragma?GCC?target'?or?`#pragma?GCC?optimize'?and?then?to?pop?back?to?the?previous?options. The?`#pragma?GCC?push_options'?and?`#pragma?GCC?pop_options'?pragmas?are?not?implemented?in?GCC?versions?earlier?than?4.4.#pragma?GCC?reset_options This?pragma?clears?the?current?#pragma?GCC?target?and?#pragma?GCC?optimize?to?use?the?default?switches?as?specified?on?the?command?line. The?`#pragma?GCC?reset_options'?pragma?is?not?implemented?in?GCC?versions?earlier?than?4.4.

#當然還有指定某個函數設置優化等級

int?max(int?a,?int?b)?__attribute__((optimize("O0"))); {return?a?<?b???a?:?b; }

#使用volatile 關鍵字避免編譯器優化

volatile 的作用是提醒CPU，如果遇到被volatile 修飾的變量，要從內存里面去取值，而不要偷懶，直接從緩存里面取值，我們一般是用在那些被中斷處理函數使用的那些變量。

如果有些代碼，你不希望CPU偷懶，那你就可以加上volatile ，讓CPU從內存取數據。

CSDN上有這樣一個例子

https://blog.csdn.net/qq_28637193/article/details/88988951今天碰到一個gcc優化相關的問題，為了讓一個頁變成臟頁（頁表中dirty位被置上），需要執行下面這段代碼：1?uint32_t?*page; 2?//?... 3?page[0]?=?page[0]; 最后一行代碼很有可能被gcc優化掉，因為這段代碼看起來沒有任何實際的作用。那么如何防止gcc對這段代碼做優化呢？設置gcc編譯時優化級別為-O0肯定是不合適的，這樣對程序性能影響會比較大。stackoverflow上的Dietrich Epp給出了一個強制類型轉換的方案：((unsigned?char?volatile?*)page)[0]?=?page[0]; 通過volatile關鍵字禁止gcc的優化

#總結、什么情況會導致這樣的問題？

1、堆棧溢出應該是一個原因，之前我有遇到的情況是棧空間設置太小，然后溢出到堆空間導致問題。

2、使用某個函數導致溢出，我們使用的函數，比如，內存拷貝函數，如果長度設置不對，也會導致影響到其他的代碼。

3、還有就是上面說的編譯器優化導致的問題。

評論說說你在開發過程總遇到過哪些奇葩的問題，又是如何解決的呢？

#推薦閱讀：

? ??專輯|Linux文章匯總

? ??專輯|程序人生

? ??專輯|C語言

嵌入式Linux

微信掃描二維碼，關注我的公眾號?

總結

以上是生活随笔為你收集整理的代码优化导致的奇葩问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。