考慮如下的宣告:
int* ptr1, ptr2; //正確的寫法如下:ptr1為指標,ptr2為整數
int* ptr1, *ptr2;用型別定義代替巨集定義是乙個好的習慣,型別定義允許編譯器檢查作用域規則,而巨集定義不一定會。
使用巨集定義輔助宣告變數,如下所示:
#define pint int*pint ptr1, ptr2;不過結果和前面所說的一致,更好的方法是使用下面的型別定義:
typedef int*pint;在使用指標之前未初始化會導致執行時錯誤,如下面的**:pint ptr1, ptr2;
int*p;指標p未被初始化,可能含有垃圾資料...printf(
"%d\n
", *p);
把指標初始化為null更容易檢查是否使用正確,即便這樣,檢查空值也比較麻煩,如下所示:
int *pi =null;我們可以使用assert函式來測試指標是否為空值:...if(pi ==null) else
assert(pi != null);
緩衝區溢位下面幾種情況可能導致緩衝區的溢位:緩衝區溢位是指當計算機向緩衝區內填充資料位數時超過了緩衝區本身的容量,使得溢位的資料覆蓋在合法資料上,理想的情況是程式檢查資料長度並不允許輸入超過緩衝區長度的字元,但是絕大多數程式都會假設資料長度總是與所分配的儲存空間相匹配,這就為緩衝區溢位埋下隱患。作業系統所使用的緩衝區又被稱為"堆疊".。在各個操作程序之間,指令會被臨時儲存在"堆疊"當中,"堆疊"也會出現緩衝區溢位。
使用malloc這樣的函式的時候一定要檢查返回值,否則可能會導致程式的非正常終止,下面是一般的方法:
float *vector = malloc(20 * sizeof(float宣告和初始化指標的常用方法如下:));if(vector ==null) else
int下面是一種看似等價但是錯誤的宣告方法:num;
int *pi = #
int參見《c迷途指標》沒有什麼可以阻止程式訪問為陣列分配的空間以外的記憶體,下面的例子中,我們宣告並初始化了三個陣列來說明這種行為:num;
int *pi;
*pi = #
#includeint執行結果如下:main()
下圖說明了記憶體分配情況:
將陣列傳給函式時,一定要同時傳遞陣列長度,這個資訊幫助函式避免越過陣列邊界
#includevoid replace(char buffer, char其中乙個例子是試圖檢查指標邊界但方法錯誤replacement, size_t size)
}int
main()
#includeint改為:i < sizeof(buffer) / sizeof(int);main()
return0;
}
有界指標是指指標的使用被限制在有效的區域內,c沒有對這類指標提供直接的支援,但是可以自己顯示地確保。如下所示:
#define size 32一種有趣的變化是建立乙個指標檢驗函式;char
name[size];
char *p =name;
if(name !=null) else
}
下面的**定義乙個函式消除無效指標:
int valid(void *ptr)
#include #include在linux平台執行結果如下:int valid(void *p)
intglobal;
int main(void
)
pointer to local var valid?
1
pointer to
static
var valid?
1
pointer to function valid?
0
pointer to heap valid?
1
pointer to end of allocated heap valid?
1
pointer to freed heap valid?
1
null
pointer valid?
0
另一種方法是利用ansi-c和c++的邊界檢查工具(cbmc)
C 執行緒安全問題
如果你的 在程序中有多個執行緒同時執行一段 如果每次執行的結果都和單執行緒執行時的結果一致,那麼就是執行緒安全的 先看下面兩段 執行結果是否一樣?int num1 0 int num2 0 for int i 0 i 1000 i for int i 0 i 1000 i console.write...
C 自賦值與異常安全問題
這個講的很不錯!因為cpp中有指標和引用,它們可以指向同乙個變數,所以會存在自賦值的問題。a i a j 如果i和j有同樣的值,這裡就是一次自賦值 px py 如果px和py指向相同的東西,這裡就是一次自賦值 自賦值一般存在 自賦值安全和異常安全,兩個問題,例如 widget widget oper...
Cookie安全問題與防範
那麼不正確地使用 cookie 有哪些安全問題呢?cookie篡改 這是最容易出現的情況,也就是直接修改 cookie 的內容。我們知道,cookie 是儲存在客戶端的,所以裡面的內容可以通過瀏覽器的控制台或者 js 進行修改的。因此 cookie 相對而言是不可信的,如果我們把一些重要的資訊,例如...