青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

glxhyt

  C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
  15 隨筆 :: 0 文章 :: 4 評論 :: 0 Trackbacks

2013年5月19日 #

http://www.who1753.com/100-bugs-in-c-cpp-opensource-projects/

俄羅斯OOO Program Verification Systems公司用自己的靜態(tài)源碼分析產品PVS-Studio對一些知名的C/C++開源項目,諸如Apache Http ServerChromiumClangCMakeMySQL等的源碼進行了分析,找出了100個典型的Bugs。個人覺得這份列表對C/C++ 程序員有一定參考意義。與其說事后用靜態(tài)工具分析,倒不如在編碼時就提高自知自覺,避免這份列表上的錯誤發(fā)生在你的代碼中,因此這里將部分摘錄一些Bugs(Bug編號這里不連續(xù),為的是對應原文的編號)并做簡要說明。原文將這份Bug列表分為了幾類,這里也將沿用這個思路。

一、數(shù)組和字符串處理錯誤

數(shù)組和字符串處理錯誤是C/C++程序中最多的一類缺陷類型。這也可以看作是我們?yōu)閾碛懈咝У氐讓觾却娌僮髂芰Χ冻龅拇鷥r。

[#1] Wolfenstein 3D項目 -"只有部分對象被clear了"

1
2
3
4
5
6
7
8
void CG_RegisterItemVisuals( int itemNum )
{
       
      itemInfo_t *itemInfo;
      
      memset( itemInfo, 0, sizeof( &itemInfo ) ); 
      
}

這里的Bug出現(xiàn)在memset那一行。代碼的真實意圖是clear iteminfo這塊內存,但調用memset時,第三個參數(shù)傳入的卻是sizeof(&iteminfo),要知道 sizeof(&itemInfo) != sizeof(itemInfo_t),前者只是一個指針的大小罷了。正確的寫法是:

memset(itemInfo, 0, sizeof(itemInfo_t)); 或memset(itemInfo, 0, sizeof(*itemInfo));

[#2] Wolfenstein 3D項目 -"只有部分Matrix被clear了"

ID_INLINE mat3_t::mat3_t( float src[ 3 ][ 3 ] ) {
memcpy( mat, src, sizeof( src ) );
}

這里的Bug出現(xiàn)在memcpy一行。程序的原意是將clear src[3][3]這個二維數(shù)組。但這里有個坑:那就是作為函數(shù)形式參數(shù)的數(shù)組名已經(jīng)退化為指針了,對其sizeof只能得到一個指針的長度,因此這里的 memcpy只是copy了一個指針的長度,沒有copy全。這里的代碼是C++代碼,原文中給出了正確的改正方法 – 傳reference:

ID_INLINE mat3_t::mat3_t( float (&src)[3][3] )
{
memcpy( mat, src, sizeof( src ) );
}

[#4] ReactOS項目 – "錯誤地計算一個字符串的長度"

static const PCHAR Nv11Board = "NV11 (GeForce2) Board";
static const PCHAR Nv11Chip = "Chip Rev B2";
static const PCHAR Nv11Vendor = "NVidia Corporation";

BOOLEAN
IsVesaBiosOk(…)
{

if (!(strncmp(Vendor, Nv11Vendor, sizeof(Nv11Vendor))) &&
!(strncmp(Product, Nv11Board, sizeof(Nv11Board))) &&
!(strncmp(Revision, Nv11Chip, sizeof(Nv11Chip))) &&
(OemRevision == 0×311))

}

Bug處在IsVesaBiosOK中那一串strncmp調用中,代碼將一個指針的size傳入strncmp作為第三個參數(shù),導致 strncmp實際只是比較了字符串的前4 or 8個字節(jié),而不是字符串的全部內容。

[#6] CPU Identifying Tool項目 – 數(shù)組越界

#define FINDBUFFLEN 64  // Max buffer find/replace size

int WINAPI Sticky (…)
{

static char findWhat[FINDBUFFLEN] = {'\0'};

findWhat[FINDBUFFLEN] = '\0';

}

bug出在"findWhat[FINDBUFFLEN] = ‘\0′;”這一行。數(shù)組的最大長度為FINDBUFFLEN,但下標的最大值應該是FINDBUFFLEN-1,而不是FINDBUFFLEN。因此這 行代碼顯然應該改為findWhat[FINDBUFFLEN-1] = '\0';

[#7] Wolfenstein 3D項目 – 數(shù)組越界

typedef struct bot_state_s
{

char teamleader[32]; //netname of the team leader

}  bot_state_t;

void BotTeamAI( bot_state_t *bs ) {

bs->teamleader[sizeof( bs->teamleader )] = '\0';

}

"sizeof( bs->teamleader )]"這行的結果值已經(jīng)超出了數(shù)組的最大邊界,正確的代碼是:

bs->teamleader[
sizeof(bs->teamleader) / sizeof(bs->teamleader[0]) – 1
] = '\0';

[#8] Miranda IM項目 – 只Copy了部分字符串

struct _textrangew
{
CHARRANGE chrg;
LPWSTR lpstrText;
} TEXTRANGEW;

const wchar_t* Utils::extractURLFromRichEdit(…)
{

::CopyMemory(tr.lpstrText, L"mailto:", 7);

}

這里的bug在于L"mailto:"是寬字符串,寬字符串中的每個字符占2或4個字節(jié)(依Compiler使用的字符集編碼而定),因此這里只 copy 7個字節(jié)顯然是不夠的,應該是7 * sizeof(wchar_t)。

[#9] CMake項目 – 循環(huán)內的數(shù)組越界

static const struct {
DWORD   winerr;
int     doserr;
} doserrors[] =
{

};

static void
la_dosmaperr(unsigned long e)
{

for (i = 0; i < sizeof(doserrors); i++)
{
if (doserrors[i].winerr == e)
{
errno = doserrors[i].doserr;
return;
}
}

}

作者原本意圖la_dosmaperr中for循環(huán)的次數(shù)等于數(shù)組的元素個數(shù),但sizeof(doserrors)返回的卻是數(shù)組占用的字節(jié)個數(shù),這遠遠大于數(shù)組元素個數(shù),因此造成數(shù)組越界。正確的寫法:

for (i = 0; i < sizeof(doserrors) / sizeof(*doserrors); i++)

[#10] CPU Identifying Tool項目 – 打印到自身的字符串

char * OSDetection ()
{

sprintf(szOperatingSystem,
"%sversion %d.%d %s (Build %d)",
szOperatingSystem,
osvi.dwMajorVersion,
osvi.dwMinorVersion,
osvi.szCSDVersion,
osvi.dwBuildNumber & 0xFFFF);

sprintf (szOperatingSystem, "%s%s(Build %d)",
szOperatingSystem, osvi.szCSDVersion,
osvi.dwBuildNumber & 0xFFFF);

}

通過sprintf,szOperatingSystem字符串將自己打印到自己里面,這是十分危險的,將導致無法預知的錯誤結果,可能會導致棧溢出等嚴重問題。

[#12] Notepad++項目 – 數(shù)組局部clear

#define CONT_MAP_MAX 50
int _iContMap[CONT_MAP_MAX];

DockingManager::DockingManager()
{

memset(_iContMap, -1, CONT_MAP_MAX);

}

代碼的原本試圖將數(shù)組_iContMap清零,但memset的第三個參數(shù)CONT_MAP_MAX并不能代表數(shù)組的真正大小,而只是數(shù)組的元素個數(shù)而已,顯然其忘記乘以sizeof(int)了。

二、未定義行為

在C/C++的語言規(guī)范中,我們常常能看到“xx is undefined”。規(guī)范中并沒有明確表明這類錯誤是什么樣子的,只是說取決于Compiler的實現(xiàn),也許Compiler會給出正確的結果,但這么使用卻是不可移植的。

[#1] Chromium項目 – 智能指針的誤用

void AccessibleContainsAccessible(…)
{

auto_ptr<VARIANT> child_array(new VARIANT[child_count]);

}

這里的問題在于使用new[]分配的內存,在智能指針釋放時卻用了delete,這將會導致未定義行為。看看autoptr的destructor就知道了:

~auto_ptr() {
delete _Myptr;
}

我們可以找一些更合適的類來fix這個問題,比如boost::scopedarray。

[#2] IPP Sample項目 – 經(jīng)典未定義行為

template<typename T, Ipp32s size> void HadamardFwdFast(…)
{
Ipp32s *pTemp;

for(j=0;j<4;j++) {
a[0] = pTemp[0*4] + pTemp[1*4];
a[1] = pTemp[0*4] – pTemp[1*4];
a[2] = pTemp[2*4] + pTemp[3*4];
a[3] = pTemp[2*4] – pTemp[3*4];
pTemp = pTemp++;

}

}

很多人一眼就看到了"pTemp = pTemp++"這行,對于這個代碼編譯器會產生兩種結果截然不同的翻譯:

pTemp = pTemp + 1;
pTemp = pTemp;

TMP = pTemp;
pTemp = pTemp + 1;
pTemp = TMP;

到底是哪種呢?依賴于編譯器的實現(xiàn),甚至是優(yōu)化級別的設定。

三、與運算優(yōu)先級相關的錯誤

[#1] MySQL工程 – !和&的運算優(yōu)先級

int ha_innobase::create(…)
{

if (srv_file_per_table
&& !mysqld_embedded
&& (!create_info->options & HA_LEX_CREATE_TMP_TABLE)) {

}

這段代碼原意是想測試create_info->options變量中幾個bit位的值是否set了,即!(create_info->options & HA_LEX_CREATE_TMP_TABLE),但由于!的運算優(yōu)先級高于&,實際邏輯變成了(!create_info->options) & HA_LEX_CREATE_TMP_TABLE了。如果想要這段代碼如期工作,就不要吝嗇小括號了。

[#2] Emule工程 – *和++的運算優(yōu)先級

STDMETHODIMP
CCustomAutoComplete::Next(…, ULONG *pceltFetched)
{

if (pceltFetched != NULL)
*pceltFetched++;

}

顯然作者原意是想對pceltFetched所指向的long型變量進行++操作,但由于*和++的運算優(yōu)先級沒有搞對,導致實際上執(zhí)行了*(pceltFetched++)的操作,而不是(*pceltFetched)++操作。

[#3] Chromium項目 – &和!=的運算優(yōu)先級

#define FILE_ATTRIBUTE_DIRECTORY 0×00000010

bool GetPlatformFileInfo(PlatformFile file, PlatformFileInfo* info) {

info->is_directory =
file_info.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY != 0;

}

這個程序員的意圖是通過測試file_info.dwFileAttributes的幾個bit位的值來判定是否是目錄,邏輯上應該是(file_info.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) != 0,但由于!=優(yōu)先級高于&,原代碼中無括號,結果邏輯變成了file_info.dwFileAttributes & (FILE_ATTRIBUTE_DIRECTORY != 0),導致is_directory將永遠求值為true。

[#4] BCmenu項目 – if和else弄混

void BCMenu::InsertSpaces(void)
{
if(IsLunaMenuStyle())
if(!xp_space_accelerators) return;
else
if(!original_space_accelerators) return;

}

這又是C語言的一個“大坑”,無奈這個BCMenu項目的程序員掉坑里了。雖然從代碼縮進上來看,else似乎是與最外層的if配對使用,但實際這段代碼的效果是:

if(IsLunaMenuStyle())
{
if(!xp_space_accelerators) {
return;
} else {
if(!original_space_accelerators) return;
}
}

這顯然不是程序員原意,看來括號必要時還是不能省略的。修改后的代碼如下:

if(IsLunaMenuStyle()) {
if(!xp_space_accelerators) return;
} else {
if(!original_space_accelerators) return;
}

四、格式化輸出錯誤

[#1] ReactOS項目 – 錯誤地輸出WCHAR字符

static void REGPROC_unescape_string(WCHAR* str)
{

default:
fprintf(stderr,
"Warning! Unrecognized escape sequence: \\%c'\n",
str[str_idx]);

}

%c是用來格式化輸出非寬字符的,這里用來輸出WCHAR顯然會得到錯誤的結果,fix solution是將%c換位%C。

[#2] Intel AMT SDK項目 – 缺少%s 【VS2010,運行可能會崩潰】

void addAttribute(…)
{

int index = _snprintf(temp, 1023,
"%02x%02x:%02x%02x:%02x%02x:%02x%02x:"
"%02x%02x:02x%02x:%02x%02x:%02x%02x",
value[0],value[1],value[2],value[3],value[4],
value[5],value[6],value[7],value[8],
value[9],value[10],value[11],value[12],
value[13],value[14],value[15]);

}

 

不解釋了,自己慢慢數(shù)和對照吧。

[#3] Intel AMT SDK項目 – 未使用的參數(shù)

bool GetUserValues(…)
{

printf("Error: illegal value. Aborting.\n", tmp);
return false;
}

然tmp是多余的。

五、書寫錯誤

[#1] Miranda IM項目 – 在if中賦值

void CIcqProto::handleUserOffline(BYTE *buf, WORD wLen)
{

else if (wTLVType = 0×29 && wTLVLen == sizeof(DWORD))

}

“wTLVType = 0×29”顯然是筆誤,應該是“wTLVType == 0×29”才對。

[#3] Clang項目 – 對象名書寫錯誤

static Value *SimplifyICmpInst(…) {

case Instruction::Shl: {
bool NUW =
LBO->hasNoUnsignedWrap() && LBO->hasNoUnsignedWrap();
bool NSW =
LBO->hasNoSignedWrap() && RBO->hasNoSignedWrap();

}

從最后一行先后使用了LBO和RBO來看,前面只用了LBO的那行很可能是有問題的,正確的應該是:

bool NUW =
LBO->hasNoUnsignedWrap() && RBO->hasNoUnsignedWrap();

[#6] G3D Content Pak項目 – 一對括號放錯了地方

bool Matrix4::operator==(const Matrix4& other) const {
if (memcmp(this, &other, sizeof(Matrix4) == 0)) {
return true;
}

}

由于括號放錯了地方,導致memcmp最后的參數(shù)變成了sizeof(Matrix4) == 0,這行代碼的正確寫法應該是:

if (memcmp(this, &other, sizeof(Matrix4)) == 0) {

[#8] Apache Http Server項目 – 多余的sizeof

PSECURITY_ATTRIBUTES GetNullACL(void)
{
PSECURITY_ATTRIBUTES sa;
sa  = (PSECURITY_ATTRIBUTES)
LocalAlloc(LPTR, sizeof(SECURITY_ATTRIBUTES));
sa->nLength = sizeof(sizeof(SECURITY_ATTRIBUTES));

}

最后一行顯然是筆誤,sizeof(sizeof(SECURITY_ATTRIBUTES))應該寫為sizeof(SECURITY_ATTRIBUTES)才對。

[#10] Notepad++項目 – 在本來應該用&的地方使用了&&

TCHAR GetASCII(WPARAM wParam, LPARAM lParam)
{

result=ToAscii(wParam,
(lParam >> 16) && 0xff, keys,&dwReturnedValue,0);

}

(lParam >> 16) && 0xff沒有什么意義,求值結果總是true。這里的代碼應該是(lParam >> 16) & 0xff。

[#12] Fennec Media Project項目 – 額外的分號

int settings_default(void)
{

for(i=0; i<16; i++);
for(j=0; j<32; j++)
{
settings.conversion.equalizer_bands.boost[i][j] = 0.0;
settings.conversion.equalizer_bands.preamp[i]   = 0.0;
}
}

這又是一個實際邏輯與代碼縮進不符的例子。作者的原意是這樣的:

for(i=0; i<16; i++)
{
for(j=0; j<32; j++)
{
settings.conversion.equalizer_bands.boost[i][j] = 0.0;
settings.conversion.equalizer_bands.preamp[i]   = 0.0;
}
}

但實際執(zhí)行代碼邏輯卻是:

for(i=0; i<16; i++)
{
;
}

for(j=0; j<32; j++)
{
settings.conversion.equalizer_bands.boost[i][j] = 0.0;
settings.conversion.equalizer_bands.preamp[i]   = 0.0;
}

這一切都是那個;導致的。

六、對基本函數(shù)和類的誤用

[#2] TortoiseSVN項目 – remove函數(shù)的誤用

STDMETHODIMP CShellExt::Initialize(….)
{

ignoredprops = UTF8ToWide(st.c_str());
// remove all escape chars ('\\')
std::remove(ignoredprops.begin(), ignoredprops.end(), '\\');
break;

}

作者意圖刪除所有'\\',但他用錯了函數(shù),remove函數(shù)只是交換元素的位置,將要刪除的元素交換到尾部trash,并且返回指向trash首地址的iterator。正確的做法應該是"v.erase(remove(v.begin(), v.end(), 2), v.end())"。

[#5] Pixie項目 – 在循環(huán)中使用alloca函數(shù)

inline  void  triangulatePolygon(…) {

for (i=1;i<nloops;i++) {

do {

do {

CTriVertex  *snVertex =
(CTriVertex *)alloca(2*sizeof(CTriVertex));

} while(dVertex != loops[0]);

} while(sVertex != loops[i]);

}

}

alloca函數(shù)在棧上分配內存,因此在循環(huán)中使用alloca可能會很快導致棧溢出。

七、無意義的代碼

[#1] IPP Samples項目 – 不完整的條件

void lNormalizeVector_32f_P3IM(Ipp32f *vec[3],
Ipp32s* mask, Ipp32s len)
{
Ipp32s  i;
Ipp32f  norm;

for(i=0; i<len; i++) {
if(mask<0) continue;
norm = 1.0f/sqrt(vec[0][i]*vec[0][i]+
vec[1][i]*vec[1][i]+vec[2][i]*vec[2][i]);
vec[0][i] *= norm; vec[1][i] *= norm; vec[2][i] *= norm;
}
}

mask是Ipp32s類型指針,這樣if (mask< 0)這句代碼顯然沒啥意義,正確的代碼應該是:

if (mask[i] < 0) continue;

[#2] QT項目 – 重復的檢查

Q3TextCustomItem* Q3TextDocument::parseTable(…)
{

while (end < length
&& !hasPrefix(doc, length, end, QLatin1String("</td"))
&& !hasPrefix(doc, length, end, QLatin1String("<td"))
&& !hasPrefix(doc, length, end, QLatin1String("</th"))
&& !hasPrefix(doc, length, end, QLatin1String("<th"))
&& !hasPrefix(doc, length, end, QLatin1String("<td"))
&& !hasPrefix(doc, length, end, QLatin1String("</tr"))
&& !hasPrefix(doc, length, end, QLatin1String("<tr"))
&& !hasPrefix(doc, length, end, QLatin1String("</table"))) {


}

這里對"<td"做了兩次check。

八、總是True或False的條件

[#1] Shareaza項目 – char類型的值范圍

void CRemote::Output(LPCTSTR pszName)
{


CHAR* pBytes = new CHAR[ nBytes ];
hFile.Read( pBytes, nBytes );

if ( nBytes > 3 && pBytes[0] == 0xEF &&
pBytes[1] == 0xBB && pBytes[2] == 0xBF )
{
pBytes += 3;
nBytes -= 3;
bBOM = true;
}

}

表達式"pBytes[0] == 0xEF"總是False。char類型的值范圍是-128~127 < 0xEF,因此這個表達式總是False,導致整個if condition總是為False,與預期邏輯不符。

[#3] VirtualDub項目 – 無符號類型總是>=0

typedef unsigned short wint_t;

void lexungetc(wint_t c) {
if (c < 0)
return;
g_backstack.push_back(c);
}

c是unsigned short類型,永遠不會小于0,也就是說if (c < 0)永遠為False。

[#8] MySQL項目 – 條件錯誤

enum enum_mysql_timestamp_type
str_to_datetime(…)
{

else if (str[0] != ‘a’ || str[0] != 'A')
continue; /* Not AM/PM */

}

if (str[0] != ‘a’ || str[0] != 'A')這個條件永遠為真。也許這塊本意是想用&&。

九、代碼漏洞

導致漏洞的代碼錯誤實際上也都是筆誤、不正確的條件以及不正確的數(shù)組操作等。但這里還是想將一些特定錯誤劃歸為一類,因為入侵者可以利用這些錯誤來攻擊你的代碼,獲取其利益。

[#1] Ultimate TCP/IP項目 – 空字符串的錯誤檢查

char *CUT_CramMd5::GetClientResponse(LPCSTR ServerChallenge)
{

if (m_szPassword != NULL)
{

if (m_szPassword != '\0')
{

}

第二個if condition check意圖檢查m_szPassword是否為空字符串,但卻錯誤的將指針與'\0'進行比較,正確的代碼應該是這樣的:

if (*m_szPassword != '\0')

[#2] Chromium項目 – NULL指針的處理

bool ChromeFrameNPAPI::Invoke(…)
{
ChromeFrameNPAPI* plugin_instance =
ChromeFrameInstanceFromNPObject(header);
if (!plugin_instance &&
(plugin_instance->automation_client_.get()))
return false;

}

一旦plugin_instance為NULL,!plugin_instance為True,代碼對&&后面的子條件求值,引用plugin_instance將導致程序崩潰。正確的做法應該是:

if (plugin_instance &&
(plugin_instance->automation_client_.get()))
return false;

[#5] Apache httpd Server項目 – 不完整的緩沖區(qū)clear

#define MEMSET_BZERO(p,l)       memset((p), 0, (l))

void apr__SHA256_Final(…, SHA256_CTX* context) {

MEMSET_BZERO(context, sizeof(context));

}

這個錯誤前面提到過,sizeof(context)只是指針的大小,將之改為sizeof(*context)就OK了。

[#7] PNG Library項目 – 意外的指針clear

png_size_t
png_check_keyword(png_structp png_ptr, png_charp key,
png_charpp new_key)
{

if (key_len > 79)
{
png_warning(png_ptr, "keyword length must be 1 – 79 characters");
new_key[79] = '\0';
key_len = 79;
}

}

new_key的類型為png_charpp,顧名思義,這是一個char**類型,但代碼中new_key[79] = ‘\0′這句顯然是要給某個char賦值,但new_key[n]得到的應該是一個地址,給一個地址賦值為’\0′顯然是有誤的。正確的寫法應該是(*new_key)[79] = '\0'。

[#10] Miranda IM項目 – 保護沒生效

void Append( PCXSTR pszSrc, int nLength )
{

UINT nOldLength = GetLength();
if (nOldLength < 0)
{
// protects from underflow
nOldLength = 0;
}

}

nOldLength椒UINT類型,其值永遠不會小于0,因此if (nOldLength < 0)這行成了擺設。

[#12] Ultimate TCP/IP項目 – 不正確的循環(huán)結束條件

void CUT_StrMethods::RemoveSpaces(LPSTR szString) {

size_t loop, len = strlen(szString);
// Remove the trailing spaces
for(loop = (len-1); loop >= 0; loop–) {
if(szString[loop] != ' ')
break;
}

}

環(huán)中的結束條件loop >= 0將永遠為True,因為loop變量的類型是size_t是unsigned類型,永遠不會小于0。

十、拷貝粘貼

和筆誤不同,程序員們決不因該低估拷貝粘貼問題,這類問題發(fā)生了太多。程序員們花費了大量時間在這些問題的debug上。

[#1] Fennec Media Project項目 – 處理數(shù)組元素時出錯

void* tag_write_setframe(char *tmem,
const char *tid, const string dstr)
{

if(lset)
{
fhead[11] = '\0';
fhead[12] = '\0';
fhead[13] = '\0';
fhead[13] = '\0';
}

}

 

咋看一下,fhead[13]做了兩次賦值,似乎沒啥問題。但仔細想一下,最后那行程序員的原意極可能是想寫fhead[14] = '\0'。問題就在這里了。

[#2] MySQL項目 – 處理數(shù)組元素時出錯

static int rr_cmp(uchar *a,uchar *b)
{
if (a[0] != b[0])
return (int) a[0] – (int) b[0];
if (a[1] != b[1])
return (int) a[1] – (int) b[1];
if (a[2] != b[2])
return (int) a[2] – (int) b[2];
if (a[3] != b[3])
return (int) a[3] – (int) b[3];
if (a[4] != b[4])
return (int) a[4] – (int) b[4];
if (a[5] != b[5])
return (int) a[1] – (int) b[5];
if (a[6] != b[6])
return (int) a[6] – (int) b[6];
return (int) a[7] – (int) b[7];
}

 

編寫這類代碼時,我猜絕大多數(shù)人會選擇Copy-Paste,然后再逐行修改,問題就發(fā)生在修改過程中,上面的代碼中當處理a[5] != b[5]時就忘記修改一個下標了:return (int) a[1] – (int) b[5];顯然這里的正確代碼應該是return (int) a[5] – (int) b[5]。

[#3] TortoiseSVN項目 文件名不正確

BOOL GetImageHlpVersion(DWORD &dwMS, DWORD &dwLS)
{
return(GetInMemoryFileVersion(("DBGHELP.DLL"),
dwMS,
dwLS)) ;
}

BOOL GetDbgHelpVersion(DWORD &dwMS, DWORD &dwLS)
{
return(GetInMemoryFileVersion(("DBGHELP.DLL"),
dwMS,
dwLS)) ;
}

GetImageHlpVersion和GetDbgHelpVersion都使用了"DBGHELP.DLL"文件,顯然GetImageHlpVersion寫錯文件名了。應該用"IMAGEHLP.DLL"就對了。

[#4] Clang項目 – 等同的函數(shù)體

MapTy PerPtrTopDown;
MapTy PerPtrBottomUp;

void clearBottomUpPointers() {
PerPtrTopDown.clear();
}

void clearTopDownPointers() {
PerPtrTopDown.clear();
}

我們看到雖然兩個函數(shù)名不同,但是函數(shù)體的內容是相同的,顯然又是copy-paste惹的禍。做如下修改即可:

void clearBottomUpPointers() {
PerPtrBottomUp.clear();
}

 

十一、Null指針的校驗遲了

這里的“遲了”的含義是先使用指針,然后再校驗指針是否為NULL。

[#1] Quake-III-Arena項目 – 校驗遲了

void Item_Paint(itemDef_t *item) {
vec4_t red;
menuDef_t *parent = (menuDef_t*)item->parent;
red[0] = red[3] = 1;
red[1] = red[2] = 0;
if (item == NULL) {
return;
}

}

 

校驗item是否為NULL前已經(jīng)使用過item了,一旦item真的為NULL,那程序必然崩潰。

十二、其他雜項

[#1] Image Processing 項目 – 八進制數(shù)

inline
void elxLuminocity(const PixelRGBus& iPixel,
LuminanceCell< PixelRGBus >& oCell)
{
oCell._luminance = uint16(0.2220f*iPixel._red +
0.7067f*iPixel._blue + 0.0713f*iPixel._green);
oCell._pixel = iPixel;
}

inline
void elxLuminocity(const PixelRGBi& iPixel,
LuminanceCell< PixelRGBi >& oCell)
{
oCell._luminance = 2220*iPixel._red +
7067*iPixel._blue + 0713*iPixel._green;
oCell._pixel = iPixel;
}

第二個函數(shù),程序員原意是使用713這個十進制整數(shù),但0713 != 713,在C中,0713是八進制的表示法,Compiler會認為這是個八進制數(shù)。

[#2] IPP Sample工程 – 一個變量用于兩個loop中

JERRCODE CJPEGDecoder::DecodeScanBaselineNI(void)
{

for(c = 0; c < m_scan_ncomps; c++)
{
block = m_block_buffer + (DCTSIZE2*m_nblock*(j+(i*m_numxMCU)));

// skip any relevant components
for(c = 0; c < m_ccomp[m_curr_comp_no].m_comp_no; c++)
{
block += (DCTSIZE2*m_ccomp

[/c]

.m_nblocks);
}

}

變量c用在了兩個loop中,這會導致只有部分數(shù)據(jù)被處理,或外部循環(huán)中止。

[#3] Notepad++項目 – 怪異的條件表達式

int Notepad_plus::getHtmlXmlEncoding(….) const
{

if (langT != L_XML && langT != L_HTML && langT == L_PHP)
return -1;

}

代碼中的那行if條件等價于 if (langT == L_PHP),顯然似乎不是作者原意,猜測正確的代碼應該是這樣的:

int Notepad_plus::getHtmlXmlEncoding(….) const
{

if (langT != L_XML && langT != L_HTML && langT != L_PHP)
return -1;

}

posted @ 2013-05-19 21:10 郭龍 閱讀(719) | 評論 (1)編輯 收藏

字符串匹配:

---willamette

在匹配串中尋找模式串是否出現(xiàn),注意和最長公共子序列相區(qū)別(LCS: Longest Common Substring)

最簡單的Brute Force算法:

首先將匹配串和模式串左對齊,然后從左向右一個一個進行比較,如果不成功則模式串向右移動一個單位。

速度最慢。

那么,怎么改進呢?

我們注意到Brute Force算法是每次移動一個單位,一個一個單位移動顯然太慢,是不是可以找到一些辦法,讓每次能夠讓模式串多移動一些位置呢?

當然是可以的。

我們也注意到,Brute Force是很不intelligent的,每次匹配不成功的時候,前面匹配成功的信息都被當作廢物丟棄了,當然,就如現(xiàn)在的變廢為寶一樣,我們也同樣可以將前面匹配成功的信息利用起來,極大地減少計算機的處理時間,節(jié)省成本。^_^

首先介紹的就是KMP算法。

原始論文:Knuth D.E., Morris J.H., and Pratt V.R., Fast pattern matching in strings, SIAM Journal on Computing, 6(2), 323-350, 1977.

這個算法實在是太有名了,大學上的算法課程除了最笨的Brute Force算法,然后就介紹了KMP算法。也難怪,呵呵。誰讓Knuth D.E.這么world famous呢,不僅拿了圖靈獎,而且還寫出了計算機界的Bible <The Art of Computer Programming>(業(yè)內人士一般簡稱TAOCP).稍稍提一下,有個叫H.A.Simon的家伙,不僅拿了Turing Award,順手拿了個Nobel Economics Award,做了AI的爸爸,還是Chicago Univ的Politics PhD,可謂全才。

KMP的思想是這樣的:

利用不匹配字符的前面那一段字符的最長前后綴來盡可能地跳過最大的距離

比如

模式串ababac這個時候我們發(fā)現(xiàn)在c處不匹配,然后我們看c前面那串字符串的最大相等前后綴,然后再來移動

下面的兩個都是模式串,沒有寫出來匹配串

原始位置ababac

移動之后 ababac

因為后綴是已經(jīng)匹配了的,而前綴和后綴是相等的,所以直接把前綴移動到原來后綴處,再從原來的c處,也就是現(xiàn)在的第二個b處進行比較。這就是KMP。

當然,有市場就有競爭,字符串匹配這么大一個市場,不可能讓BF和KMP全部占了,于是又出現(xiàn)了幾個強勁的對手。

第一個登場的是Horspool算法。

論文:Horspool R.N., 1980, Practical fast searching in strings, Software - Practice & Experience, 10(6):501-506

Horspool算法的思想很簡單的。不過有個創(chuàng)新之處就是模式串是從右向左進行比較的。很好很強大,為后來的算法影響很大。

匹配串:abcbcsdxzcxx

模式串:cbcac

這個時候我們從右向左進行對暗號,c-c,恩對上了,第二個b-a,不對啊,我們應該怎么辦?難道就這么放棄么。于是,模式串從不匹配的那個字符開始從右向左尋找匹配串中不匹配的字符b的位置,結果發(fā)現(xiàn)居然有,趕快對上趕快對上,別耽誤了。

匹配串:abcbcsdxzcxx

模式串: cbcac

然后繼續(xù)從最右邊的字符從右向左進行比較。這時候,我們發(fā)現(xiàn)了,d-c不匹配啊,而且模式穿里面沒有噢,沒辦法,只好移動一個模式串長度的單位了。

匹配串:abcbcsdxzcxx

模式串: cbcac

第二個上來的是Boyer-Moore算法。

是一個很復雜的算法,當然,雖然理論上時間復雜度和KMP差不多,但是實際上卻比KMP快數(shù)倍,可見實踐是檢驗真理的唯一標準。

原始論文:R.S.Boyer, J.S.Moore, A fast string searching algorithm , Communications of the ACM,20(10):762-772 ,1977

分為兩步預處理,第一個是bad-character heuristics,也就是當出現(xiàn)錯誤匹配的時候,移位,基本上就是做的Horspool那一套。

第二個就是good-suffix heuristics,當出現(xiàn)錯誤匹配的時候,我還要從不匹配點向左看啊,以前匹配的那段子字符串是不是在模式串本身中還有重復的啊,有重復的話,那么我就直接把重復的那段和匹配串中已經(jīng)匹配的那一段對齊就是了。再比較

匹配串:abaccbabbazz

模式串:cbadcba

我們看到已經(jīng)匹配好了cba,但是c-d不匹配,這個時候我們發(fā)現(xiàn)既可以采用bad-character heuristics,也可以使用good-suffix heuristics(模式串:cbadcba),在這種情況下,邪不壓正。毅然投奔good。移動得到

匹配串:abaccbabbazz

模式串: cbadcba

可是,我們有時候也發(fā)現(xiàn),已經(jīng)匹配好的那一部分其實并沒有再有重復了的啊。這個時候,我們發(fā)現(xiàn)已經(jīng)匹配好的那串字符串有一部分在開頭重新出現(xiàn)了,那么,趕快,對齊吧。

匹配串:abacccbbbazz

模式串:cbadccb

然后得到

匹配串:abacccbbbazz

模式串: cbadccb

當兩種Good-Suffix出現(xiàn)的時候,取移動距離最大的那個。

最后一個是Sunday算法,實際上比Boyer-Moore還快,呵呵。長江后浪推前浪。

原始論文:Daniel M. Sunday, A very fast substring search algorithm, Communications of the ACM, v.33 n.8, p.132-142, Aug. 1990

看原始論文的題目,D.M. Sunday貌似是故意想氣氣Boyer-Moore兩位大牛似的。呵呵。不過實際上的確Sunday算法的確比BM算法要快,而且更簡單。

Sunday的算法思想和Horspool有些相似,但是。當出現(xiàn)不匹配的時候,卻不是去找匹配串中不匹配的字符在模式串的位置,而是直接找最右邊對齊的右一位的那個字符在模式串的位置。

比如:

匹配串:abcbczdxzc

模式串:zbcac

恩,這里我們看到b-a沒有對上,我們就看匹配串中的z在模式串的位置,然后,嘿嘿。

匹配串:abcbczdxzc

模式串: zbcac

如果模式串中的沒有那個字符怎么辦呢?很簡單,跳過去唄。

匹配串:abcbcedxzcs

模式串:zbcac

e不在模式串中出現(xiàn)

那么我們就

匹配串:abcbcedxzcs

模式串: zbcac

 

實際上,現(xiàn)在還有很多很多字符串匹配算法,這里只是簡單介紹了一下最常使用的五種算法,更多算法可以參考一下http://www.inf.fh-flensburg.de/lang/algorithmen/algo.htm,8過這個是德文網(wǎng)站,有的網(wǎng)頁沒有英文版的哦。

posted @ 2013-05-19 16:58 郭龍 閱讀(743) | 評論 (0)編輯 收藏

2012年5月15日 #

1:指針問題:
錯誤代碼:
//A.cpp
T gTemp;
void GetA(T *p)
{
   p = &gTemp;
}

//B.cpp
T iInfo;
GetA(&iInfo);
或者
T *piInfo;
GetA(piInfo);

正確的是
//A.cpp
T gTemp;
T* GetA()
{
  return &gTemp;
}

//B.cpp
T *piInfo = GetA();

解決方案:
<<你必須知道的495個C語言問題>>
5.4 我有個函數(shù),它應該接受并初始化一個指針 void f(int *ip) { static int dummy = 5; ip = &dummy;} 但是當我如下調用時: int *ip; f(ip); 調用者的指針卻沒有任何變化。 你確定函數(shù)初始化的是你希望它初始化的東西嗎?請記住在 C 中, 參數(shù)是通過值傳遞的。被調函數(shù)僅僅修改了傳入的指針副本。你需要傳入指針的地址 (函數(shù)變成接受指針的指針), 或者讓函數(shù)返回指針。


同理下面也是錯誤的
void Swap(T* rht, T* lht)
{
T *pTemp = rht;
rht = lht;
lht = pTemp;
}

2: 計算算法時間問題

start = beginTime();
for (int i = 0; i < 100; ++ i)
   for (int j = 0; j < 1000; ++ j)
{
      //轉化函數(shù):
      A......
      //算法
      B.......
}

End = beginTime();

錯誤地方:A....花費2毫秒

   結果測試出現(xiàn)很大問題:
   A....花費兩毫秒
   100*1000*2 = 200s = 3.3分鐘

 修改方案:
 
   //轉化函數(shù):
   A......
   放在外面進行轉化
   

   start = beginTime();
   for (int j = 0; j < 1000; ++ j)
   {
      //轉化函數(shù):
     A......
   }

   for (int i = 0; i < 100; ++ i)
      for (int j = 0; j < 1000; ++ j)
   {
      //算法
      B.......
   }

  End = beginTime();

3: Hash 算法

4:for(u_short i = 100; i >= 0; --i)
   修改:
     for (u_short i = 100; i > 0; --i)
     for(int i = 100; i >= 0; --i)

5:讀寫文件, 發(fā)送消息,最好定義一個頭,那樣
   容易知道讀取的是什么,讀取的是否錯誤
 // 消息頭
 struct TMSG_HEADER
 {
  char    cMsgID;   // 消息標識

  TMSG_HEADER(char MsgID = INVALID_MSG)
   : cMsgID(MsgID)
  {
  }
 };


 // 請求傳送的文件名
 // 客戶端傳給服務器端的是全路徑名稱
 // 服務器傳回給客戶端的是文件名
 struct TMSG_FILENAME : public TMSG_HEADER
 {
  char szFileName[256];  // 保存文件名的字符數(shù)組

  TMSG_FILENAME()
   : TMSG_HEADER(MSG_FILENAME)
  {
  }
 };

 // 傳送文件長度
 struct TMSG_FILELENGTH : public TMSG_HEADER
 {
  long lLength;

  TMSG_FILELENGTH(long length)
   : TMSG_HEADER(MSG_FILELENGTH), lLength(length)
  {

  }
 };


累了,以后再寫吧,↖(^ω^)↗
posted @ 2012-05-15 23:27 郭龍 閱讀(517) | 評論 (3)編輯 收藏

2012年2月6日 #

2012 目標

1.
學一種腳本語言 python
學習一下數(shù)據(jù)結構, 練習編程之美

2.
學習網(wǎng)絡通信
看書自學

3.
研讀CppUnit自動化測試
學習交叉編譯環(huán)境


復習去年學習的Linux知識 C/C++知識
復習工作中總結點點滴滴

posted @ 2012-02-06 23:09 郭龍 閱讀(256) | 評論 (0)編輯 收藏

2011年11月27日 #

     摘要: 回調函數(shù)應用 Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->  1#include <iostream>  2using namespace std; &...  閱讀全文
posted @ 2011-11-27 21:05 郭龍 閱讀(392) | 評論 (0)編輯 收藏

     摘要: 越來越感到自己基礎差了今天看到 李先靜老師 系統(tǒng)程序員成長計劃 那本書上寫道 編寫通用的鏈表的于是自己練習寫了一下,主要是 void* --> int*  int*--> void*沒想到指針的生命周期,整暈了,調試了好久。  typedef struct tagNode_t{    struct tagNode_t...  閱讀全文
posted @ 2011-11-27 16:02 郭龍 閱讀(313) | 評論 (0)編輯 收藏

2009年04月18日 星期六 下午 08:21
有時會遇到一種很特殊的調試需求,對當前正在運行的其它進程進行調試(正是我今天遇到的情形)。這種情況有可能發(fā)生在那些無法直接在調試器中運行的進程身上,例如有的進程 只能在系統(tǒng)啟動時運行。另外如果需要對進程產生的子進程進行調試的話,也只能采用這種方式。GDB可以對正在執(zhí)行的程序進行調度,它允許開發(fā)人員中斷程序 并查看其狀態(tài),之后還能讓這個程序正常地繼續(xù)執(zhí)行。

GDB提供了兩種方式來調試正在運行的進程:一種是在GDB命令行上指定進程的PID,另一種是在GDB中使用“attach”命令。例如,開發(fā)人員可以先啟動debugme程序,讓其開始等待用戶的輸入。示例如下:

#./debugme
Enter a string to count words:


接下去在另一個虛擬控制臺中用下面的命令查出該進程對應的進程號:

# ps -ax | grep debugme
555 pts/1 S 0:00 ./debugme


得到進程的PID后,就可以使用GDB對其進行調試了:

# gdb debugme 555
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
Attaching to program: /home/xiaowp/debugme, process 555
Reading symbols from /lib/libc.so.6...done.
……


在上面的輸出信息中,以Attaching to program開始的行表明GDB已經(jīng)成功地附加在PID為555的進程上了。另外一種連接到其它進程的方法是先用file命令加載調試時所需的符號表,然后再通過“attaché”命令進行連接:

(gdb) file /home/xiaowp/debugme
Reading symbols from /home/xiaowp/debugme...done.
(gdb) attach 555
……


如果想知道程序現(xiàn)在運行到了哪里,同樣可以使用“backtrace”命令。當然也可以使用“step”命令對程序進行單步調試。

在完成調試之后,不要忘記用detach命令斷開連接,讓被調試的進程可以繼續(xù)正常運行。
posted @ 2011-11-27 00:22 郭龍 閱讀(468) | 評論 (0)編輯 收藏

2011年11月26日 #

[轉自]http://www.wutianqi.com/?p=1822

二維數(shù)組和二級指針的傳遞問題

再次看這篇文章,感覺說的好多都是廢話,在文章最前面補充一句話:
[]的優(yōu)先級高于*”,大家可以帶著這句話看下面的~~~
========================
再一次的見證了自己的基礎不牢靠。。。幸好發(fā)現(xiàn)得早,看見網(wǎng)上說,華為的一個面試題就考了這個方面的。

借那道華為的面試題引出問題,題目:

char **p, a[16][8]; 問:p=a是否會導致程序在以后出現(xiàn)問題?為什么?

可能有一部分朋友會回答正確,這里他們認為,a[]是一級指針,a[][]就是二級指針。那這個到底對不對呢?

OK,用事實說話:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Author: Tanky Woo
// Blog:    www.WuTianQi.com
// Note:   驗證二維數(shù)組與二級指針的傳遞問題
#include <iostream> 
using namespace std; 
 
void Test(char **p) 
{ 
    cout << p[0][0] << endl; 
} 
 
int main() 
{ 
    char a[2][3]; 
    Test(a); 
    return 0; 
}

結果報錯:

1
2
// error C2664: “Test”: 不能將參數(shù) 1 從“char [2][3]”轉換為“char  **”
//                          與指向的類型無關;轉換要求 reinterpret_cast、C  樣式轉換或函數(shù)樣式轉換

于是乎,我看了下《C專家編程》里10.5節(jié)—使用指針向函數(shù)傳遞一個多維數(shù)組

方法一:

函數(shù)是:

1
void fun1(int arr[2][3]);

這種方法導致只能處理2行3列的int型數(shù)組。

方法二:

可以省略第一維的長度。

函數(shù)是:

1
void fun2(int arr[][3]);

這種方法的限制略微寬松了一些,但是還是只能處理每行是3個整數(shù)長度的數(shù)組。

函數(shù)也可以寫成:

1
void fun2_2(int (*arrr)[3]);

方法三:

創(chuàng)建一個一維數(shù)組,數(shù)組中的元素是指向其他東西的指針。也可以說是二級指針。

函數(shù)是:

1
int fun3(int **arr);

注意:只有把二維數(shù)組改為一個指向向量的指針數(shù)組的前提下才可以這么做!

比如:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <iostream> 
using namespace std; 
 
void test(char **ptr) 
{ 
    cout << *ptr << endl; 
} 
 
int main() 
{ 
    char *p[3] = {"abc", "def", "ghi"}; 
    test(p); 
    return 0; 
}

在《C專家編程》10.3節(jié)的小啟發(fā)里講的很透徹:(以下這段文字及對比一定要認真分析!)

數(shù)組和指針參數(shù)是如何被編譯器修改的?

數(shù)組名被改寫成一個指針參數(shù)”規(guī)則并不是遞歸定義的。數(shù)組的數(shù)組會被改寫成“數(shù)組的指針”,而不是“指針的指針”:

實參 所匹配的形參

數(shù)組的數(shù)組 char c[8][10]; char (*)[10]; 數(shù)組指針

指針數(shù)組 char *c[10]; char **c; 指針的指針

數(shù)組指針(行指針) char (*c)[10]; char (*c)[10]; 不改變

指針的指針 char **c; char **c; 不改變

我在CSDN上專門為這個問題提問過:

http://topic.csdn.net/u/20101221/12/da817bda-4e88-44df-bdf8-40e8f44aacb8.html?2076366575

最后我總結下討論結果:

只要實參的類型與形參的類型一致(或可轉換)就行。

為什么這么說呢?

piaojun_pj朋友給了一段代碼,分析得很給力:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
// VectorTest.cpp : 定義控制臺應用程序的入口點。 
// 
 
#include "stdafx.h" 
#include <iostream> 
using namespace std; 
 
int _tmain(int argc, _TCHAR* argv[]) 
{ 
    int arr1[3]; 
    int arr2[3]; 
    int arr3[3]; 
    int * ptr; 
    // ptr1是一個指向 int [3] 的指針,即ptr的類型和&arr1的類型是一樣的,注意:arr1指向的內存區(qū)域定長 
    int ptr1[3][3]={{1,2,3},{1,2,3},{1,2,3}}; 
    // ptr2是一個指向 int * 的指針,即ptr2的類型和&ptr是一樣的,注意:ptr指向的內存區(qū)域不定長 
    int * ptr2[3]={arr1,arr2,arr3}; 
    // ptr3是一個指向 int [3] 的指針,即ptr3的類型和&arr1的類型是一樣的,注意:arr1指向的內存區(qū)域定長 
    int(* ptr3)[3]=&arr1; 
    ptr3=ptr1; // 沒錯,他們的類型相同 
    // ptr3=ptr2;//error 無法從“int *[3]”轉換為“int (*)[3] 
    // ptr4是一個指向 int * 的指針,即ptr4的類型和&ptr是一樣的,注意:ptr指向的內存區(qū)域不定長 
    int ** ptr4; 
    //ptr4=&arr1; //error 無法從“int (*)[3]”轉換為“int ** 
    ptr4=ptr2; // 沒錯,他們的類型相同 
    //ptr4=ptr3; // error 無法從“int (*)[3]”轉換為“int ** 
    return 0; 
}
posted @ 2011-11-26 23:41 郭龍 閱讀(427) | 評論 (0)編輯 收藏

2011年11月21日 #

     摘要:     入職一年了,這一年自己學到許多,但是忘記也很多,于是決定定下心來整理以前學到的,并且繼續(xù)學習        二維數(shù)組和二級指針,這真是頭疼的問題,困擾了我好幾次,       先轉一下wanpengcoder的二維數(shù)組和二級指針 ...  閱讀全文
posted @ 2011-11-21 23:55 郭龍 閱讀(5621) | 評論 (0)編輯 收藏

2010年10月31日 #

      由于自己以前是學數(shù)學的,許多計算機知識都不懂,所以學許多東西
時候感覺的很累.......于是記錄一下最近學習經(jīng)歷,一致勉勵自己,繼續(xù)努力,繼續(xù)奮斗!   

     C++程序設計看到了異常,感覺真是受益匪淺,許多東西講的很深,于是反復看,
并結合effect c++(看了兩遍,還是有許多東西不懂)
 
     Linux_c編程一戰(zhàn)式學習據(jù)說是將Linux最好的書之一,看了文件,進程,線程,信號
     感覺講的卻是很好,許多知識反復看了兩遍,才看懂....

     看到了一段時候又買了UNIX環(huán)境高級編程,看了幾十頁,正在繼續(xù)......

      在這其中又把林銳的c/c++ 高質量編程看了兩遍,覺得指針,內存那塊
 講的太好了,\(^o^)/~
   
      沒事隨手看看C語言程序設計現(xiàn)代方法,和編程之美,很不錯了C
  語言書,和算法書。
 
  
posted @ 2010-10-31 22:48 郭龍 閱讀(478) | 評論 (0)編輯 收藏

僅列出標題  下一頁
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            国产精品色在线| 久久国产精品第一页| 欧美精品日韩一本| 中文在线资源观看网站视频免费不卡 | 亚洲风情在线资源站| 女女同性精品视频| 欧美激情精品久久久久久免费印度| 亚洲人成在线观看网站高清| 亚洲美洲欧洲综合国产一区| 国产精品www| 久久字幕精品一区| 欧美激情亚洲| 午夜一区二区三视频在线观看| 欧美一区二区日韩一区二区| 亚洲大片精品永久免费| 亚洲另类黄色| 国内一区二区在线视频观看| 亚洲第一偷拍| 欧美性猛片xxxx免费看久爱| 久久精品视频在线| 欧美日韩p片| 久久久久久久波多野高潮日日 | 性欧美大战久久久久久久免费观看| 午夜精品一区二区三区电影天堂| 亚洲电影天堂av| 日韩视频免费观看高清在线视频| 国产欧美日韩在线播放| 亚洲国产精品国自产拍av秋霞| 国产精品a久久久久| 美女精品在线观看| 国产精品a久久久久久| 欧美成人亚洲成人日韩成人| 国产精品久久久久9999吃药| 久久中文字幕一区二区三区| 欧美在线欧美在线| 亚洲美女视频在线观看| 国产日韩欧美精品在线| 亚洲国产欧美日韩另类综合| 国产欧美精品一区二区色综合 | 这里只有精品丝袜| 1024精品一区二区三区| 亚洲免费伊人电影在线观看av| 亚洲人在线视频| 久久夜色精品国产欧美乱| 午夜精品一区二区三区在线| 欧美黄在线观看| 欧美激情aⅴ一区二区三区| 国产日韩欧美亚洲一区| 一本在线高清不卡dvd| 亚洲精品少妇网址| 久久亚洲综合色| 久久久青草青青国产亚洲免观| 国产精品外国| 中文欧美在线视频| 亚洲一区二区久久| 欧美四级剧情无删版影片| 亚洲破处大片| 亚洲美女视频在线免费观看| 蜜乳av另类精品一区二区| 美女网站在线免费欧美精品| 国产一区二区中文| 欧美在线地址| 久久久精品日韩| 国精品一区二区三区| 午夜免费久久久久| 久久精品成人一区二区三区蜜臀 | 欧美精品一区在线观看| 久久综合九色欧美综合狠狠| 国内久久精品| 久久久久久久成人| 欧美成人一区二免费视频软件| 亚洲电影专区| 欧美精品在线一区二区| 日韩视频第一页| 欧美一级片在线播放| 国产日韩精品在线播放| 久久精品91久久久久久再现| 久久综合九色综合欧美狠狠| 亚洲第一黄色| 欧美国产日韩亚洲一区| 一本综合久久| 久久久91精品国产一区二区三区 | 国产精品一区免费视频| 欧美一区二区三区精品电影| 美女诱惑一区| 99在线精品免费视频九九视| 欧美成人自拍视频| 中文久久精品| 免费久久99精品国产自在现线| 亚洲国产精品久久久久久女王| 欧美激情精品| 亚洲色图综合久久| 久久婷婷影院| 日韩一区二区免费看| 国产精品女主播一区二区三区| 久久国产精品免费一区| 欧美成人午夜激情在线| 亚洲图片在线观看| 免费日韩av电影| 亚洲天堂成人| 亚洲成色777777在线观看影院 | 一本色道久久综合亚洲精品不| 欧美在线免费视频| 日韩视频久久| 国产主播一区二区三区| 欧美v国产在线一区二区三区| 亚洲视频综合在线| 亚洲国产精品精华液2区45| 欧美一级视频精品观看| 亚洲精华国产欧美| 国产欧美91| 欧美日韩免费一区| 老司机免费视频久久| 亚洲欧美资源在线| 日韩午夜激情av| 亚洲大黄网站| 欧美尤物一区| 一区二区不卡在线视频 午夜欧美不卡'| 国产亚洲欧美一区二区三区| 美女91精品| 亚洲综合国产| 一区二区精品在线| 亚洲精品国产精品国自产在线| 久久精品视频免费播放| 亚洲女同性videos| 国产精品99久久99久久久二8 | 亚洲在线视频免费观看| 99国产精品久久久久久久| 一区二区三区在线看| 国产欧美成人| 国产欧美日韩亚洲一区二区三区| 欧美日本国产在线| 欧美日韩成人综合在线一区二区| 老牛国产精品一区的观看方式| 亚洲在线视频| 亚洲欧美偷拍卡通变态| 亚洲曰本av电影| 亚洲一区国产一区| 亚洲免费人成在线视频观看| 一区二区日韩精品| 亚洲精品一区中文| 亚洲人成网站精品片在线观看| 亚洲国产精品久久91精品| 欧美黄免费看| 亚洲国产欧美久久| 亚洲精品1区2区| 亚洲成人在线视频网站| 欧美v日韩v国产v| 欧美激情精品久久久久久| 欧美a级一区| 亚洲国产精品一区二区第一页 | 欧美国产一区在线| 欧美日本高清视频| 国产精品videosex极品| 国产精品日韩欧美一区二区| 国产精品一级久久久| 国产自产在线视频一区| 亚洲国产成人精品女人久久久| 亚洲欧洲精品一区| 亚洲在线观看视频网站| 久久精品盗摄| 亚洲福利视频专区| 一区二区免费在线播放| 亚洲欧美激情一区| 久久综合色综合88| 一本色道久久综合狠狠躁篇怎么玩 | 欧美视频在线观看免费| 国产精品成人观看视频国产奇米| 国产欧美精品日韩精品| 亚洲第一精品夜夜躁人人躁| 一本色道久久88亚洲综合88 | 国产丝袜一区二区| 影音先锋另类| 亚洲视频在线一区| 久久综合久久88| 最新国产乱人伦偷精品免费网站| 一区二区三区久久网| 久久久水蜜桃| 欧美劲爆第一页| 国产精品网站在线播放| 国产精品亚洲产品| 日韩视频一区二区三区在线播放免费观看 | 日韩亚洲欧美综合| 久久福利精品| 亚洲电影免费观看高清完整版| 在线亚洲一区| 牛人盗摄一区二区三区视频| 欧美视频一区二区三区| 国产揄拍国内精品对白| 亚洲精品日韩激情在线电影| 久久爱91午夜羞羞| 日韩一区二区电影网| 久久亚洲精品一区| 国产日韩欧美黄色| 亚洲男同1069视频| 亚洲欧洲综合另类| 老鸭窝亚洲一区二区三区| 国产欧美在线视频| 午夜精品久久久久久| 日韩视频在线播放|