這本應(yīng)是一個無須爭論的問題——當(dāng)然必須調(diào)用。

stdarg（或varargs，下略）中提供的功能就是一種契約：
“你按我的約定方式使用這些宏
——即必須調(diào)用va_end
——我就給你提供實現(xiàn)可變長參數(shù)列表所需要的功能。”


使用stdarg本來是很簡單的事情
——按照一個簡單的契約（另見相關(guān)鏈接）辦事就可以了
——根本無須了解其具體實現(xiàn)。

有人樂意去研究該功能是如何實現(xiàn)的， 也很好。


可是某些人
——或通過研究其的實現(xiàn)，或通過實踐
——發(fā)現(xiàn)他所使用的平臺下， va_end是可以忽略的。
之后，他就開始大放厥詞 ： “va_end是不必要的！”

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

---

讓我們看看對va_end的兩種態(tài)度：

---

一、 va_end能省則省？

假設(shè)你使用的某個C/C++編譯器，提供的va_end是可忽略的。
比如msvc中的va_end的實現(xiàn)如下：

通常直接使用va_start的函數(shù)（假設(shè)叫f）的實現(xiàn)體會很短。：
1. 用va_start初始化va_list
2. 調(diào)用一個使用va_list參數(shù)的函數(shù)（假設(shè)叫vf）
（vf 是一個固定參數(shù)列表的函數(shù)）。

因為f的實現(xiàn)體非常短， 一眼望穿。
所以你能確保vf返回后， ap不會再被你使用。

因此， 將ap置空除了浪費(fèi)CPU周期， 沒有實際意義， 是這樣嗎？


        一、1.  編譯器參與優(yōu)化

你能發(fā)現(xiàn)代碼末尾ap不再被使用， va_end將其置空毫無意義。
那么，你的編譯器能發(fā)現(xiàn)這個問題么？

請查證一下。
如果編譯器也知道， 并且沒有為va_end生成任何代碼， 那么省略va_end就是不必要的了。

        一、2. 編譯器不參與優(yōu)化

你編譯器真為va_end生成了無意義并且令人感到無法接受的機(jī)器碼時，該怎么辦？


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

那么，你省略va_end好了。
但請不要宣揚(yáng)一些帶有誤導(dǎo)性質(zhì)的言辭。
當(dāng)你說“va_end是不需要”的時候， 請附帶說明：
1. 你的平臺
2. 你不考慮跨平臺


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

注意， 其他編譯器包括（但不限于）：
——不同架構(gòu)上的編譯器
——相同架構(gòu)上的不同編譯器產(chǎn)品
——相同架構(gòu)上的相同編譯器產(chǎn)品的不同版本。

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


即使你在源代碼中寫入 ：

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


如果在被移植的編譯器上：
1. 省略va_end將導(dǎo)致函數(shù)不能正常返回（見附錄）
也許立馬就能發(fā)現(xiàn)這個bug。
崩掉了嘛， 當(dāng)然要引起“重視”。

2. 省略va_end不會立馬崩潰， 而是導(dǎo)致內(nèi)存泄露（見附錄）
情況就很嚴(yán)重了。
程序依然運(yùn)行“良好”。
但是調(diào)用一次函數(shù)， 就泄漏一點點內(nèi)存。

這恐怕就要花很多時間才能查出來了。
如果項目時間再緊一點， 也許根本就來不及修復(fù)這個bug就發(fā)布了。
反正漏得也“不多”， 你說是吧？

---

二、 va_end能留則留

我們何不換個方式？

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

代碼移植本質(zhì)就是： 不對平臺（CPU、OS、Compiler等等）產(chǎn)生依賴。
stdarg就是標(biāo)準(zhǔn)庫提供的一種實現(xiàn)可變長參數(shù)列表的可移植方式。
我們沒理由棄之不用。

如果我們在源代碼中堅持使用va_end：
——至少在這點上，就不會對編譯器產(chǎn)生依賴（而省略va_end，就是一種依賴）。
——移植的時候， 自然無須為其操心。

2. va_end令編譯器產(chǎn)生了令人無法接受的無用代碼時
——通常，這是不會發(fā)生的。 編譯器廠商會考慮這個事情。

比如上面的va_end宏， 會產(chǎn)生一次不必要的賦值操作， 但通常會被編譯器優(yōu)化為空。
即使沒有被優(yōu)化為空， 一次賦值操作， 真的就是不可容忍的么？

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

---

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

從一個使用過va_start()的函數(shù)中退出之前，必須調(diào)用一次va_end()。
這是因為va_start可能以某種方式修改了堆棧，這種修改可能導(dǎo)致返回無法完成，va_end()能將有關(guān)的修改復(fù)原。
                ——《C++程序設(shè)計語言》 第3版、特別版， p139
——即上面提到的 “立即崩潰”。


我們務(wù)必記住，在使用完va_list變量后一定要調(diào)用宏va_end。
在大多數(shù)C實現(xiàn)上，調(diào)用va_end與否并無區(qū)別。
但是，某些版本的va_start宏為了方便對va_list的遍歷，就給參數(shù)列表動態(tài)分配內(nèi)存。
這樣一種C實現(xiàn)很可能利用va_end宏來釋放此前動態(tài)分配的內(nèi)存；
如果忘記調(diào)用宏va_end，最后得到的程序可能在某些機(jī)型上沒有問題，而在另一些機(jī)型上則發(fā)生“內(nèi)存泄露”。
                ——《C陷阱與缺陷》， p161
——即上面提到的“內(nèi)存泄露”。



…… 最后，必須在函數(shù)返回之前調(diào)用va_end，以完成一些必要的清理工作。
                ——《C程序設(shè)計語言》 第2版， p137

……在所有參數(shù)處理完畢后， 且在退出函數(shù)f之前，必須調(diào)用宏va_end一次 ……
                ——《C程序設(shè)計語言》 第2版， p232

 

---

相關(guān)鏈接：

——可變長參數(shù)列表誤區(qū)與陷阱——va_arg不可接受的類型
http://m.shnenglu.com/ownwaterloo/archive/2009/04/21/unacceptable_type_in_va_arg.html
這是使用stdarg提供的功能需要遵守契約之一。
契約本身仍然是簡單的。
契約背后的原理也許比較晦澀， 但也可以不必關(guān)心。

---

本作品采用知識共享署名-非商業(yè)性使用-相同方式共享 2.5 中國大陸許可協(xié)議進(jìn)行許可。

轉(zhuǎn)載請注明 ：
文章作者 - OwnWaterloo
發(fā)表時間 - 2009年04月21日
原文鏈接 - http://m.shnenglu.com/ownwaterloo/archive/2009/04/21/is_va_end_necessary.html