[問題] 潛在的記憶體問題?

看板C_and_CPP (C/C++)作者 (今天早上)時間16年前 (2010/06/27 14:06), 編輯推噓1(1022)
留言23則, 3人參與, 最新討論串1/1
小弟現在正在寫一個處理字串的程式 程式是讀檔->process->output這樣的程序 但是想問一個問題 小弟為了將避免處理不必要的字串 而去移動檔案指標 但是用的方法是while(fgetc(FILE*)!=';'){} (移動到;的下一個就停住) 這樣會不會有問題呀 還有就是在處理字串的時候 因為我會用一個char*去接strchr出來的字串 假設是這樣好了 char *temp,temp2[20]; temp=(char*)malloc(20); . . . temp=strchr(temp2,'('); 此時temp會是一個"(XXXXXX"的東西 但是我連'('都不要 假如我寫 temp++; 這樣去甩開'(' 這樣...不知道會不會出問題? 不知道以上兩個方法會不會有甚麼潛在的記憶體問題呢? 謝謝各位 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.132.15.156

06/27 14:09, , 1F
你手寫 temp++ 就要記得檢查自己結尾的 NULL。
06/27 14:09, 1F

06/27 14:22, , 2F
可是假如測資確定一定不會讓temp++指到NULL呢?
06/27 14:22, 2F

06/27 14:24, , 3F
這就要看你是為了什麼寫這程式而定了。
06/27 14:24, 3F

06/27 14:25, , 4F
str 開頭的函式預設往後掃的時候都會檢查 NULL。
06/27 14:25, 4F

06/27 14:25, , 5F
因為 C 的字串就是 null-terminated string。
06/27 14:25, 5F

06/27 14:26, , 6F
就精神上來說,不檢查 NULL 等於「語意上不視為字串」。
06/27 14:26, 6F

06/27 14:27, , 7F
但是如果這只是一個小測驗或是作業,那就隨便你了...
06/27 14:27, 7F

06/27 14:31, , 8F
瞭解了 那while(fgetc(FILE*)!=';')去掃檔尾呢Q_Q?
06/27 14:31, 8F

06/27 14:45, , 9F
在這之前你可能要想一個問題,如果檔案裡沒有 ; 的話,
06/27 14:45, 9F

06/27 14:45, , 10F
你的 while loop 要怎樣停下來。
06/27 14:45, 10F

06/27 14:46, , 11F
因為這個部分跟你標題講的記憶體問題不同,我才沒特別說。
06/27 14:46, 11F

06/27 14:49, , 12F
嗯 其實那是每一行的結尾(;) 做完這個loop就可以讀下一行
06/27 14:49, 12F

06/27 14:50, , 13F
我是想問說fgetc沒有char去接 一直讀究竟會不會有事情
06/27 14:50, 13F

06/27 18:16, , 14F
fgetc不接無所謂, 就像有時我們會用getchar類的函數放
06/27 18:16, 14F

06/27 18:16, , 15F
main最後當作PAUSE來用.
06/27 18:16, 15F

06/27 18:18, , 16F
但是, 你temp的例子, temp存了malloc來的空間, 你卻又
06/27 18:18, 16F

06/27 18:18, , 17F
拿它來收strchr的結果, 那馬上就mem leak了....@_@"
06/27 18:18, 17F

06/27 18:20, , 18F
另外, strchr只是回傳第一個參數裡找到第二個參數的第一
06/27 18:20, 18F

06/27 18:21, , 19F
個位址, 找到後++位址只要不超過原來第一參數的可用空間
06/27 18:21, 19F

06/27 18:21, , 20F
自然是不會有問題; int a[20]; int *p=&a[10]; p++;
06/27 18:21, 20F

06/27 18:22, , 21F
上面的例子基本上不會有問題, strchr只是加了search與多
06/27 18:22, 21F

06/27 18:22, , 22F
了一些condition而已@_@"
06/27 18:22, 22F

06/27 20:14, , 23F
喔喔! 我改
06/27 20:14, 23F
文章代碼(AID): #1C9kfGPM (C_and_CPP)
文章代碼(AID): #1C9kfGPM (C_and_CPP)