※ 引述《windows2k (程式宅 <囧>)》之銘言：
: 開發平台(Platform): (Ex: VC++, GCC, Linux, ...)
: VC++/GCC/CLANG
: 額外使用到的函數庫(Library Used): (Ex: OpenGL, ...)
: None
: 問題(Question)：
: volatile大概是C/C++最難了解的關鍵字之一
: 最近在看完這篇[How to zero a buffer](http://bit.ly/1wmpbys)產生的問題
: 在開啟最佳化之後，對照Assembly Code，所有的編譯器會捨棄掉stack上的memset。
: 不過如果照他的方式刻一個，會發現所有Compiler都會做清空的動作
: static void
: secure_memzero(void * p, size_t len)
: {
: volatile uint8_t * _p = p;
: while (len--) *_p++ = 0;
: }
: 不過中間有句話不太明瞭
: The C standard states that accesses to volatile objects are part of the
: unalterable observable behaviour — but it says nothing about accesses via
: lvalue expressions with volatile types. Consequently a sufficiently
: intelligent compiler can still optimize the buffer-zeroing away in this case
: — it just has to prove that the object being accessed was not originally
: defined as being volatile.
針對這段敘述, 我分享自己的理解給你參考. (抱歉, 好像有點時間了~~)
In particular, the C standard states that the observable behaviour includes
accesses to volatile objects.
首先, 第一句話與文章最一開始提到 volatile 的地方要表達的意思一樣
(In particular, the C standard states that the observable behaviour includes
accesses to volatile objects), access volatile objects 是一個'會被看見'的行為,
compiler 不會對此做 optimize. 但以 lvalue expressions with volatile type 去
access object (即這段文字的上面的例子), C standard 沒有提到這種 case 的
behavior. 最後, 一個夠聰明的 compiler 只要證明所 access 的 object 不是原先就
被定義為 volatile, 它依然可以做 optimization (所以 secure_memzero() 同樣可能被
optimize).
這篇文章要探討的是如何避免 compiler 在特定狀況時, 因為 optimization 而衍生出的
安全性問題. 其中利用 volatile 的特性是一個可能的方式, 而且在幾個 compiler 上的
確有用 (This does trick a few more compilers).
至於為什麼 compiler 會有這樣的行為, 第一段 code 下面有解釋, 最後一句話:
While this completely subverts our intention, it is perfectly legal: The
observable behaviour of the program is unchanged by the optimization.
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 180.176.79.128
※ 文章網址: http://www.ptt.cc/bbs/C_and_CPP/M.1412382073.A.739.html