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

            MySpace

              C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
              18 隨筆 :: 2 文章 :: 10 評論 :: 0 Trackbacks

            又想起了malloc 與 free

            malloc 負責申請內存,free 負責釋放。 malloc 申請多少, free 就釋放多少,不管該內存片里是什么數據。
            舉個例子
            先申請了100MB的空間,指針 p 指向該內存段的頭地址
            void *p = malloc(1024 * 1024 * 100);

            申請100MB的空間,指針 p 指向該內存段的頭地址,P 是一個指向整形的指針
            int *p = (int*)malloc(1024 * 1024 * 100);

            無論 p 是什么類型的指針,執行 free(p); 的時候都將釋放 100 MB 的內存。

            在釋放該段內存之前再定義一個指針 pp ,指向該內存段的第 sizeof(int) 個字節
            void *pp = (int*)p + 1;

            向該指針拷貝一塊內存,并以 INT 的形式輸出

            int i = 100;
            memcpy(pp, &i, sizeof(int));
            cout << "*pp = " << *((int*)(pp)) << endl;

            一切都很正常,沒有問題。如果我們改成這樣

            int i = 100;
            memcpy(pp, &i, sizeof(int));
            cout << "*pp = " << *((int*)(pp)) << endl;
            free(p);
            cout << "*pp = " << *((int*)(pp)) << endl;

            在準備執行最后一句的時候,這100MB的內存已經被釋放掉了。此時執行最后一句會出現什么樣的情況呢?
            在 windows 下用 VC2005 編譯后運行,系統提示錯誤,告訴我們訪問內存出錯。
            在 SunOS 5.8 下,用 gcc version 3.4.2  編譯后運行,一切正常。而且 pp 指向的數據也沒有變化。

            于是我想:
            一種可能是 VC 在 free 的時候將該內存段全部清零或初始化,而在 GCC 下只是將該段內存的占用權
            釋放掉了,對該段內存數據沒有做什么修改。
            另一種可能是 VC 和 GCC 都沒有修改該段內存,只是 VC 在訪問該段內存時要先做占有權的判斷,如果沒有
            占有權則認為讀寫操作是非法的。而占有權并不是給特定的指針,只要編譯器 MALLOC 過了就算有占有權了。


             

            再看一例代碼:

            定義一個結構體
              typedef struct AA
             {
              int _i;
              char _c;
              double _d;
             } AAA;
             cout << "sizeof(AAA) = " << sizeof(AAA) << endl;  //長度是 16

              AAA aaa;
             aaa._i = 10;
             aaa._c = 'c';
             aaa._d = 1.5;
             
            開始我們的測試

             void* p = malloc(1);
             memcpy(p, &aaa, sizeof(AAA)); // 只申請一個字節,但是給它拷貝一個 AAA 結構體過去
             
             cout << "((AAA*)p)->_i = " << ((AAA*)p)->_i << endl;
             cout << "((AAA*)p)->_c = " << ((AAA*)p)->_c << endl;
             cout << "((AAA*)p)->_d = " << ((AAA*)p)->_d << endl;
             cout << "sizeof(*((AAA*)p)) = " << sizeof(*((AAA*)p)) << endl;
             
             一直到此處都很“正常”,sizeof(*((AAA*)p)) = 16。
             如果我們此時 free(p); 在 VC 下會有問題,是內存堆棧被破壞,但在 GCC 下就沒有問題。
             
            換個花樣來看看

             AAA *pa = (AAA*)malloc(1);
             pa->_i = aaa._i;
             pa->_c = aaa._c;
             pa->_d = aaa._d;

             cout << "pa->_i = " << pa->_i << endl;
             cout << "pa->_c = " << pa->_c << endl;
             cout << "pa->_d = " << pa->_d << endl;
             cout << "sizeof(*pa) = " << sizeof(*pa) << endl;
             一直到此處都很“正常”,sizeof(*pa) = 16。
             如果我們此時 free(pa); 在 VC 下會有問題,還是內存堆棧被破壞,但在 GCC 下就沒有問題。
             
            還是最上面那句話:malloc 申請多少, free 就釋放多少,不管該內存片里是什么數據。但是 VC(也可能是 WINDOWS) 就會做檢查,
            當指針的類型大小小于等于 malloc 的數量的時候則忽略過去,反之則報錯。這些都是內存越界造成的,windows會出于安全的
            角度去考慮這個問題,但是用 GCC 編譯出來的程序在 SUN OS 5.9 上則不會進行這樣的檢測,雖然提高了效率但是不安全。
            因為對于越界的這部分內存中的內容將會是不確定的。
            我在想,這個檢測是 GCC(打開了警告參數也沒有警告) 的機制還是SUN OS 5.9的?
            還可以聯想另外一個問題,編譯器中的數據類型只是個描述,給編譯器處理(尋找)數據的時候用的,無論你將
            數據類轉換來轉換去,都不會對數據的實體進行變更,數據還是那個數據,只是有可能后面追加了一些東西或是
            “切”掉了一部分。此處的“切”并不是真正把數據抹去了,而是編譯器根據新的數據類型去尋址就有可能有一些數據看不到了。
            就像將 DOUBLE 轉換成 INT ,內存中的數據沒有變,只是編譯器只能看到前面4個字節。

            posted on 2008-08-05 23:00 yang-chunlei 閱讀(480) 評論(0)  編輯 收藏 引用
            久久久久久久综合日本| 日本五月天婷久久网站| 久久精品国产久精国产| AV色综合久久天堂AV色综合在| AAA级久久久精品无码片| 久久人搡人人玩人妻精品首页| 亚洲欧美一级久久精品| 色偷偷88888欧美精品久久久| 久久99热国产这有精品| 久久久久亚洲AV无码专区首JN| 久久ZYZ资源站无码中文动漫| 日本国产精品久久| 秋霞久久国产精品电影院| 久久久久国产精品嫩草影院| 91久久福利国产成人精品| 日韩精品久久无码人妻中文字幕| 国产精品99久久不卡| 日本久久久久亚洲中字幕| 久久毛片免费看一区二区三区| 久久精品国产精品亚洲毛片| 中文字幕精品久久久久人妻| 国产精品热久久毛片| 国内精品久久久久影院日本| 亚洲综合精品香蕉久久网| 久久精品无码一区二区三区日韩| 国产精品久久久久久影院| 亚洲乱码中文字幕久久孕妇黑人| 久久夜色精品国产www| 精品国产综合区久久久久久| 精品午夜久久福利大片| 国产精品免费福利久久| 噜噜噜色噜噜噜久久| 武侠古典久久婷婷狼人伊人| 国产三级精品久久| 久久婷婷五月综合色99啪ak| 99久久精品国产一区二区三区| 狠色狠色狠狠色综合久久| 色综合久久综合网观看| 精品免费久久久久国产一区 | 尹人香蕉久久99天天拍| 久久夜色精品国产|