1. 程式人生 > >va_start之後va_end是必須的嗎?

va_start之後va_end是必須的嗎?



這本應是一個無須爭論的問題——當然必須呼叫。

stdarg(或varargs,下略)中提供的功能就是一種契約
“你按我的約定方式使用這些巨集
——即必須呼叫va_end
——我就給你提供實現可變長引數列表所需要的功能。”


使用stdarg本來是簡單的事情
——按照一個簡單的契約(另見相關連結)辦事就可以了
——根本無須瞭解其具體實現。

有人樂意去研究該功能是如何實現的, 也很好。


可是某些人
——或通過研究其的實現,或通過實踐
——發現他所使用的平臺下, va_end是可以忽略的。
之後,他就開始大放厥詞 : “va_end是不必要的!”

由此, 造成一些不必要的誤解與爭論。


讓我們看看對va_end的兩種態度:


一、 va_end能省則省?

假設你使用的某個C/C++編譯器,提供的va_end是可忽略的。
比如msvc中的va_end的實現如下: #define
 va_end(apap = (va_list)0  /* 將ap置空 */

通常直接使用va_start的函式(假設叫f)的實現體會很短。:
1. 用va_start初始化va_list
2. 呼叫一個使用va_list引數的函式(假設叫vf
(vf 是一個固定引數列表的函式)。

因為f的實現體非常短, 一眼望穿。
所以你能確保vf返回後, ap不會再被你使用。

因此, 將ap置空除了浪費CPU週期, 沒有實際意義, 是這樣嗎?


        一、1.  編譯器參與優化

你能發現程式碼末尾ap不再被使用, va_end將其置空毫無意義。
那麼,你的編譯器能發現這個問題麼?

請查證一下。
如果編譯器也知道, 並且沒有為va_end生成任何程式碼, 那麼省略va_end就是不必要的了。

        一、2. 編譯器不參與優化

你編譯器真為va_end生成了無意義並且令人感到無法接受的機器碼時,該怎麼辦?


                一、2.1 你只在該編譯器下工作

那麼,你省略va_end好了。
但請不要宣揚一些帶有誤導

性質的言辭。
當你說“va_end是不需要”的時候, 請附帶說明:
1. 你的平臺
2. 你考慮跨平臺


                一、2.2 需要要考慮移植到其他編譯器

注意, 其他編譯器包括(但不限於):
——不同架構上的編譯器
——相同架構上的不同編譯器產品
——相同架構上的相同編譯器產品的不同版本

需要分析在該編譯器下,對va_end的處理是否依然可以被省略
——顯然,這是一項乏味的工作。


即使你在原始碼中寫入 :

/* va_end is trivial, omit it */

也難保它不會被遺忘
—— 移植一個程式的時候有太多工作要做。
這麼一個不起眼的地方, 會被想起來麼?


如果在被移植的編譯器上:
1. 省略va_end將導致函式不能正常返回(見附錄)
也許立馬就能發現這個bug。
崩掉了嘛, 當然要引起“重視”。

2. 省略va_end不會立馬崩潰, 而是導致記憶體洩露(見附錄)
情況就很嚴重

了。
程式依然執行“良好”。
但是呼叫一次函式, 就洩漏一點點記憶體。

這恐怕就要花很多時間才能查出來了。
如果專案時間再緊一點, 也許根本就來不及修復這個bug就釋出了。
反正漏得也“不多”, 你說是吧?


二、 va_end能留則留

我們何不換個方式?

1.  堅持使用va_end
——即便我們心裡清楚它沒做什麼有用的事情也是如此。

程式碼移植本質就是: 不對平臺(CPU、OS、Compiler等等)產生依賴
stdarg就是標準庫提供的一種實現可變長引數列表的可移植方式。
我們沒理由棄之不用。

如果我們在原始碼中堅持使用va_end:
——至少在這點上,就不會對編譯器產生依賴(而省略va_end,就是一種依賴)。
——移植的時候, 自然無須為其操心。

2. va_end令編譯器產生了令人無法接受無用程式碼時
——通常,這是不會發生的。 編譯器廠商會考慮這個事情。

比如上面的va_end巨集, 會產生一次不必要的賦值操作, 但通常會被編譯器優化為空。
即使沒有被優化為空, 一次賦值操作, 真的就是不可容忍的麼?

如果確實不能容忍, 作為一種特殊情形, 可以這樣 :

#if defined(COMPILER1) || defined(COMPILER2|| .../*special situation
        the machine code generated by these compliers is unacceptable, omit it
    
*/#else/* general situation */
    va_end(ap);
#endif


附錄 —— 看看大牛們是怎麼說的。

從一個使用過va_start()的函式中退出之前,必須呼叫一次va_end()。
這是因為va_start可能以某種方式修改了堆疊,這種修改可能導致返回無法完成,va_end()能將有關的修改復原。
                ——《C++程式設計語言》 第3版、特別版, p139
——即上面提到的 “立即崩潰”。


我們務必記住,在使用完va_list變數後一定要呼叫巨集va_end。
大多數C實現上,呼叫va_end與否並無區別
但是,某些版本的va_start巨集為了方便對va_list的遍歷,就給引數列表動態分配記憶體
這樣一種C實現很可能利用va_end巨集來釋放此前動態分配的記憶體;
如果忘記呼叫巨集va_end,最後得到的程式可能在某些機型上沒有問題,而在另一些機型上則發生“記憶體洩露”。
                ——《C陷阱與缺陷》, p161
——即上面提到的“記憶體洩露”。



…… 最後,必須在函式返回之前呼叫va_end,以完成一些必要的清理工作。
                ——《C程式設計語言》 第2版, p137

……在所有引數處理完畢後, 且在退出函式f之前必須呼叫巨集va_end一次 ……
                ——《C程式設計語言》 第2版, p232