vc 2005 sp1下isspace函數(shù)的debug版本對(duì)中文處理有問(wèn)題
今天碰到一個(gè)怪問(wèn)題，從別人那兒拿來(lái)的一段代碼先在gcc下過(guò)了，又移植到vc下編譯，結(jié)果debug時(shí)老是有assert錯(cuò)誤。看了一下代碼，錯(cuò)誤發(fā)生在一個(gè)trim函數(shù)中。trim函數(shù)接受一個(gè)char*類型的字符串參數(shù)，去掉字符串前后的空格、制表符等空白字符。其中判斷是否是空白字符用的是isspace函數(shù)。按照一般的想法，char*字符串里的字符編碼無(wú)論是GBK還是utf-8，因?yàn)槎技嫒軦SCII，所以isspace函數(shù)都不應(yīng)該發(fā)生問(wèn)題。但事實(shí)是只要是字符串有中文，無(wú)論是gbk還是utf-8編碼，isspace內(nèi)都有assert錯(cuò)誤。為了便于說(shuō)明，把其中的代碼抽像出來(lái)如下：
char* lpszBuffer = (char*)"高";
int nLen = (int)strlen(lpszBuffer);
for( int i=0;i
{
printf("0x%x %dn",lpszBuffer[i],isspace(lpszBuffer[i]) );
}
這段代碼在debug編譯的情況下會(huì)assert失敗。沒(méi)有辦法，只好跟蹤到c運(yùn)行庫(kù)里，isspace的實(shí)現(xiàn)如下(在"_ctype.c"文件里)：
extern __inline int (__cdecl isspace) (
int c
)
{
if (__locale_changed == 0)
{
return __fast_ch_check(c, _SPACE);
}
else
{
return (_isspace_l)(c, NULL);
}
}
跟蹤發(fā)現(xiàn)，__locale_changed的值為0，走第一個(gè)分支，調(diào)用__fast_ch_check，它其實(shí)是個(gè)宏定義，最后進(jìn)入_chvalidator函數(shù)，它的實(shí)現(xiàn)代碼如下：
extern "C" int __cdecl _chvalidator(
int c,
int mask
)
{
_ASSERTE((unsigned)(c + 1) <= 256);
return _chvalidator_l(NULL, c, mask);
}
錯(cuò)誤就發(fā)生在這個(gè)函數(shù)的第一行“ _ASSERTE((unsigned)(c + 1) <= 256);”。
代碼看到這里，錯(cuò)誤的原因基本也就出來(lái)了。“高”的GBK編碼是“b8 df”，調(diào)用isspace函數(shù)是逐個(gè)字節(jié)判斷，但是isspace和_chvalidator接受的參數(shù)都是int，這樣就會(huì)產(chǎn)生一個(gè)char到int的轉(zhuǎn)型，在vc下，char默認(rèn)是"signed char"，這樣char“b8”轉(zhuǎn)型到int后，會(huì)變成一個(gè)負(fù)數(shù)，然后在assert的時(shí)候，又強(qiáng)制轉(zhuǎn)型為unsigned，它又變成了一個(gè)非常巨大的正數(shù)，自然assert就失敗了。
為什么在gcc下沒(méi)有錯(cuò)誤？gcc下的isspace函數(shù)實(shí)現(xiàn)我倒沒(méi)看，不過(guò)我的gcc中的char默認(rèn)就是“unsighed char”，所以即使isspace的實(shí)現(xiàn)跟上面的一樣，也不會(huì)產(chǎn)生問(wèn)題。
另：在win32 release和wince下，也不會(huì)有上述問(wèn)題，因?yàn)檫@幾種環(huán)境下isspace的實(shí)現(xiàn)跟上面不一樣。
問(wèn)題找到了，剩下的就看怎么解決了。
首先用用一個(gè)最簡(jiǎn)單的方法，既然問(wèn)題發(fā)生在轉(zhuǎn)型上，只要把char的默認(rèn)類型改為unsigned char就可以了，vc也提供了這個(gè)選項(xiàng)。但這有幾個(gè)問(wèn)題，一是別人用我的代碼的時(shí)候還得修改編譯選項(xiàng)，二是修改了整個(gè)工程的編譯選項(xiàng)可能會(huì)對(duì)其它代碼產(chǎn)生不好的影響。
既然上面的方法不大好操作，那就再想想別的方法。經(jīng)觀察發(fā)現(xiàn)，isspace函數(shù)中靠__locale_changed變量控制流程走向，搜索整個(gè)crt的源代碼，發(fā)現(xiàn)__locale_changed的值只有在setlocale函數(shù)中發(fā)生了改變。最后，我把代碼修改成如下：
#if defined(WIN32) && defined(_DEBUG)
char* locale = setlocale( LC_ALL, ".OCP" );
#endif
char* lpszBuffer = (char*)"高";
int nLen = (int)strlen(lpszBuffer);
for( int i=0;i
{
printf("0x%x %dn",lpszBuffer[i],isspace(lpszBuffer[i]) );
}
這樣在debug版本上就不會(huì)再有問(wèn)題，但是可能其中仍有隱患，等到具體碰到的時(shí)候再說(shuō)吧。先把目前的工作繼續(xù)下去。