1. 緣起

這幾天調gcc 7.5.0 +glibc 2.23的交叉編譯工具鏈，由于gcc 7.5.0的默認打開Werr，偶然發現了glibc一個隱藏了二十年的世紀大bug，

這個bug在glibc 2.0版本剛開始就引入了，但直到2.25版本才最終解決，即使按glibc-2.0.1.bin.alpha-linux.tar.gz 版本的發布時間（04-Feb-1997）到glibc-2.25.tar.bz2 的發布時間（05-Feb-2017），也持續了20年加一天，

用gcc 7.5編譯的時候如果使能-Wall -Werror這2個選項（-Wall 英文說明是Enable most warning messages，表示使能大多數告警上報；-Werror表示所有告警都當錯誤來上報，不可忽略），會報下面的錯誤：

nss_nisplus/nisplus-alias.c: In function '_nss_nisplus_getaliasbyname_r':
nss_nisplus/nisplus-alias.c:300:12: error: argument 1 null where non-null expected [-Werror=nonnull]
   char buf[strlen (name) + 9 + tablename_len];
            ^~~~~~~~~~~~~
In file included from ../include/string.h:54:0,
                 from ../sysdeps/generic/hp-timing-common.h:40,
                 from ../sysdeps/x86_64/hp-timing.h:38,
                 from ../include/libc-internal.h:7,
                 from ../sysdeps/x86_64/nptl/tls.h:29,
                 from ../sysdeps/x86_64/atomic-machine.h:20,
                 from ../include/atomic.h:50,
                 from nss_nisplus/nisplus-alias.c:19:
../string/string.h:394:15: note: in a call to function 'strlen' declared here
 extern size_t strlen (const char *__s)
               ^~~~~~
nss_nisplus/nisplus-alias.c:303:39: error: '%s' directive argument is null [-Werror=format-truncation=]
   snprintf (buf, sizeof (buf), "[name=%s],%s", name, tablename_val);
                                       ^~
cc1: all warnings being treated as errors

如果不使能-Werror，編譯器最多會上報告警，程式還是能正常編譯通過，上面2個告警分別對strlen的入參和snprintf的字串格式化引數做了非空檢查，根據代碼邏輯判斷，兩處代碼如果執行到，呼叫的入參確實都必然是空指標，

 源代碼如下： 

276 enum nss_status
277 _nss_nisplus_getaliasbyname_r (const char *name, struct aliasent *alias,
278                 char *buffer, size_t buflen, int *errnop)
279 {
280   int parse_res;
281  
282   if (tablename_val == NULL)
283     {
284       __libc_lock_lock (lock);
285  
286       enum nss_status status = _nss_create_tablename (errnop);
287  
288       __libc_lock_unlock (lock);
289  
290       if (status != NSS_STATUS_SUCCESS)
291     return status;
292     }
293  
294   if (name != NULL)
295     {
296       *errnop = EINVAL;
297       return NSS_STATUS_UNAVAIL;
298     }
299  
300   char buf[strlen (name) + 9 + tablename_len];
301   int olderr = errno;
302  
303   snprintf (buf, sizeof (buf), "[name=%s],%s", name, tablename_val);
304  
305   nis_result *result = nis_list (buf, FOLLOW_PATH | FOLLOW_LINKS, NULL, NULL);

可以看出300行對應的strlen函式的入參要求非空，但由于294行做了一個非空的判斷并回傳，也就是說如果294行的if判斷為非，那說明name指標必然為空，這時strlen來獲取字串長度就會例外，

具體會怎么例外？我們可以寫個簡單的例子：

1 #include <stdio.h>
2 #include <string.h>
3 int main()
4 {
5     printf("%d", strlen(NULL));
6     return 0;
7 }

默認不帶任何引數的情況下，gcc會上報告警，但仍然可以編譯通過，執行后會出現Segmentation fault：

 1 gcc  test1.c
 2 test1.c: In function 'main':
 3 test1.c:5:5: warning: null argument where non-null required (argument 1) [-Wnonnull]
 4      printf("%d", strlen(NULL));
 5      ^
 6 test1.c:5:12: warning: format '%d' expects argument of type 'int', but argument 2 has type 'size_t {aka long unsigned int}' [-Wformat=]
 7      printf("%d", strlen(NULL));
 8             ^
 9 
10 ./a.out
11 Segmentation fault

編譯如果加上-Wall -Werror選項會直接報error編譯失敗：

1 gcc -Wall -Werror test1.c
2 test1.c: In function 'main':
3 test1.c:5:5: error: null argument where non-null required (argument 1) [-Werror=nonnull]
4      printf("%d", strlen(NULL));
5      ^
6 test1.c:5:12: error: format '%d' expects argument of type 'int', but argument 2 has type 'size_t {aka long unsigned int}' [-Werror=format=]
7      printf("%d", strlen(NULL));
8             ^
9 cc1: all warnings being treated as errors

問題的直接原因還是因為libc庫里面的strlen沒有做空指標保護，直接訪問入參對應的記憶體了，所以實際上就會出現空指標訪問，程式例外退出，

同樣的303行的snprintf也要求%s對應的引數不能是空指標，否則也會出現Segmentation fault，

從上面的分析可以看出，有一些warning實際上本身就是錯誤，應該作為error來處理，在glibc的漫長進化程序中，有很多執行路徑可能真的沒走到（如果沒有100%覆寫率的單元測驗，也沒有完善的代碼review機制，可能永遠也沒人會發現），或者確實不影響功能的正常發布，但這些告警指向的代碼，一旦走到就會出現致命錯誤，

最終glibc修正代碼其實也很簡單，就是將294行的“if (name != NULL)”修改成了“if (name == NULL)”，一個運算子用反了，

很多影響非常大的bug，定位之后的實際修改都是簡單的一兩行代碼的事情，但問題的關鍵是要發現bug并定位bug，并且在bug修正之后的波及測驗作業，

這個bug之所有能持續20年沒人發現，只能說明glibc中應該還有很多代碼在實際場景中沒有用到，

2. 編譯器的進化

下面這個表格給出了不同clang或者gcc版本新增的代碼靜態檢查的告警計數，為了顯得簡潔一點，clang7或者更老的clang的所有告警做了一下匯總，gcc 4或者更老的gcc版本的所有告警也做了一下匯總，從中可以看出每次大版本升級，編譯器團隊都給開發團隊提供了一些新的工具能更多的發現自己代碼bug的神器，

下面匯總的1204個告警中，有119個告警是clang和gcc都提供的，其他966個告警至少從名稱上看是gcc或者clang特有的，其中clang（以clang 12來算）特有的告警檢查項有803個，gcc（以gcc 9來算）有178個，單從這個指標看clang在靜態檢查方面是遠勝于gcc的，"2012 ACM Software System Award"大獎實至名歸，

不過clang本身是為了支撐llvm的，所以很多與llvm不相關的功能都是直接呼叫的gcc的庫介面，可以認為clang是站在gcc的巨人肩膀上來發布的自己的產品，

當前各個公司都引入了很多靜態檢查的工具來完善代碼質量，但第一步還是要把靜態檢查工具的老祖宗，也就是編譯器，自帶的靜態檢查功能用足用好，再考慮消除其他靜態檢查工具的問題比較靠譜，走好這一步，引入clang非常必要，

標籤：C++

上一篇：一起用Python做個自動化彈鋼琴腳本，我竟然彈出了《天空之城》！

下一篇：C語言 const 修飾函式回傳值 - C語言零基礎入門教程