• <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>

            牽著老婆滿街逛

            嚴以律己,寬以待人. 三思而后行.
            GMail/GTalk: yanglinbo#google.com;
            MSN/Email: tx7do#yahoo.com.cn;
            QQ: 3 0 3 3 9 6 9 2 0 .

            Win32開發中最易踏上的地雷

            from:http://www.programfan.com/article/showarticle.asp?id=2776

              有關微軟編程技術的書籍可謂多如牛毛,但讀來讀去感覺還是MSDN比較權威。這里就拿一個例子來說吧,可能讓很多剛開始學習Win32 API程序設計、甚至是一些已經有一定Win32 API經驗的人感覺大汗淋漓。

              在學習Win32 API程序設計時,“第一課”我想都會學到“事件循環”吧?很多書給出了類似這樣的經典示例:

            int WINAPI _tWinMain(HINSTANCE hInst, HINSTANCE hPrevInst, LPCTSTR lpCmdLine, int nCmdShow)
            {
             MSG msg;
             
             
            while(GetMessage(&msg, NULL, 00))
             
            {
              TranslateMessage(
            &msg);
              DispatchMessage(
            &msg);
             }

             
             
            return (int)msg.wParam;
            }
             

              沒錯吧?多么熟悉的事件循環,它可以很好地工作,當收到一個WM_QUIT事件的時候,GetMessage()返回0,我們的程序得以正常退出。因此,幾乎任何一本講述Win32 API程序設計的書籍或文章,不論國內的還是國外的,都會以這樣一個程序作為第一章中的示例。

              然而,就在前不久,和往常一樣,閑來無事就翻起MSDN來,不知怎么的,就跑來看這個再熟悉不過的GetMessage()函數的參考來了。這一看不要緊,頭頂頓時冒出虛汗——原來這么多年我們這么寫程序,不能說是錯誤的,但絕對是有漏洞!來看MSDN上對于GetMessage()函數的講解(節選):

              注意:下面一段文字節選自MSDN Library Online,原文參見:

            http://msdn.microsoft.com/
            library/
            en-us/
            winui/
            winui/
            windowsuserinterface/
            windowing/
            messagesandmessagequeues/
            messagesandmessagequeuesreference/
            messagesandmessagequeuesfunctions/
            getmessage.asp

            >Return Value

            >If the function retrieves a message other than WM_QUIT, the return value is nonzero.

            >If the function retrieves the WM_QUIT message, the return value is zero.

            >If there is an error, the return value is -1. For example, the function fails if hWnd is an invalid window handle or lpMsg is an invalid pointer. To get extended error information, call GetLastError.

            >Warning
            >Because the return value can be nonzero, zero, or -1, avoid code like this:

            while (GetMessage( lpMsg, hWnd, 0, 0)) ...

            >The possibility of a -1 return value means that such code can lead to fatal application errors. Instead, use code like this:

            BOOL bRet;

            while( (bRet = GetMessage( &msg, NULL, 00 )) != 0)

             
            if (bRet == -1)
             
            {
              
            // handle the error and possibly exit
             }

             
            else
             
            {
              TranslateMessage(
            &msg); 
              DispatchMessage(
            &msg); 
             }

            }
             

              草譯如下,希望更多的朋友能夠看清:

              返回值

               如果該函數收到一個除WM_QUIT之外的事件,其返回值為一個非零值。

               如果該函數收到一個WM_QUIT事件,其返回值為零。

               如果該函數發生錯誤,其返回值為-1。例如,如果hWnd是一個無效的窗口句柄,或者lpMsg是一個無效指針,該函數就會失敗。要獲得額外的錯誤信息,請調用GetLastError。

              警告

               由于該函數的返回值可能是非零的、零或者-1,請避免這樣做:

            while (GetMessage( lpMsg, hWnd, 0, 0)) ...

               返回值-1出現的可能性意味著這樣的代碼會導致應用程序的致命錯誤。因此,我們應該編寫這樣的代碼:

            BOOL bRet;

            while( (bRet = GetMessage( &msg, NULL, 00 )) != 0)

             
            if (bRet == -1)
             
            {
              
            // handle the error and possibly exit
             }

             
            else
             
            {
              TranslateMessage(
            &msg); 
              DispatchMessage(
            &msg); 
             }

            }
             

              看到了嗎?我們這么長時間以來一直書寫的代碼,卻在這個“警告”中被“明令禁止”了!可能有的朋友會想,這樣的調用不可能出錯啊,我們通常都在啟動事件循環之前成功地創建了窗口,并且檢查了是否成功,因此傳遞給GetMessage()函數的窗口句柄肯定是有效的;而且,我們通常在堆棧上分配msg,并通過求址運算符(&)來計算它的地址并傳遞給GetMessage()函數,也不大可能出現無效指針???但是,還記得程序設計的基本原理之一嗎——永遠不要假設任何事情!因此,看來我們該把過去寫的代碼拿出來好好審視一遍了。

              這里僅提到了一個這樣被我們忽視的技術細節,我想一定還有很多、更多這樣的被忽視的東西存在!希望本文拋磚引玉,大家把你們發現的類似東西分享出來,讓大家都能夠寫出更加安全健壯的程序吧!

              P.S. 小感受一則,希望不要挨板磚……

              很多人都罵Windows是如何如何不安全,“緩沖區溢出”甚至變成連小學生都能隨口說出的“名詞”。其實,很多的Windows API都盡量保證了其執行的成功,并且以各種形式反饋給程序員,同時也在文檔中進行了詳細的描述。然而,又有多少人真正好好閱讀了這些講解?有多少技術作者、技術作家在下筆之前認真瀏覽了MSDN Library?

              Windows是安全的,不安全的是我們想當然的作風! 
            本欄文章均來自于互聯網,版權歸原作者和各發布網站所有,本站收集這些文章僅供學習參考之用。任何人都不能將這些文章用于商業或者其他目的。( ProgramFan.Com )

            posted on 2007-04-11 19:32 楊粼波 閱讀(224) 評論(0)  編輯 收藏 引用

            久久婷婷五月综合色99啪ak| 精品久久久久久久久中文字幕| 久久青青草原综合伊人| 国产精品欧美久久久久无广告 | 欧美日韩精品久久久久| 中文字幕无码精品亚洲资源网久久| 久久亚洲AV无码精品色午夜| 国产三级久久久精品麻豆三级 | 久久人人爽人人爽人人爽| 人妻无码中文久久久久专区| 久久久久国产一级毛片高清版| 久久亚洲国产成人影院网站| 无码国内精品久久人妻| 久久久无码精品午夜| 久久国产精品一区二区| 色综合久久夜色精品国产| 国产999精品久久久久久| 精品免费久久久久久久| 亚洲欧洲久久久精品| 国产激情久久久久影院小草| 久久香蕉超碰97国产精品| 亚洲欧洲精品成人久久奇米网| 2020最新久久久视精品爱| 99久久99久久精品免费看蜜桃| 亚洲国产成人精品女人久久久 | 久久久久久亚洲AV无码专区| 性高湖久久久久久久久AAAAA| 94久久国产乱子伦精品免费| 热re99久久6国产精品免费| 久久亚洲精品国产亚洲老地址| 91亚洲国产成人久久精品网址| 99久久成人国产精品免费| 久久久无码人妻精品无码| 无码人妻精品一区二区三区久久| 亚洲欧洲久久av| 亚洲七七久久精品中文国产 | 91久久精品91久久性色| 无码人妻少妇久久中文字幕蜜桃 | 久久人人爽人人爽AV片| 久久精品国产亚洲7777| 日本亚洲色大成网站WWW久久|