[問題] 在sub block做fopen並回傳問題

看板C_and_CPP (C/C++)作者時間11月前 (2023/12/05 23:43), 編輯推噓9(907)
留言16則, 10人參與, 11月前最新討論串1/1
開發平台(Platform): (Ex: Win10, Linux, ...) CentOS 編譯器(Ex: GCC, clang, VC++...)+目標環境(跟開發平台不同的話需列出) GCC 問題(Question): 最近寫程式時,碰到在sub block做fopen,然後找到指定關鍵字後回傳 我是這樣寫的 #include<stdlib.h> #include<stdio.h> int main(){ int status=-1; status=sub_test("test"); printf("Status is %d\n",status); return 0; } int sub_test(char *filename){ fid_rd=fopen(filename,"r"); while(fscanf(fid_rd,"%s",&tmp)!=NULL){ if(strcmp("PASS",tmp)==0) return 1; } fclose(fid_rd); return 0; } 這邊這樣寫,在編譯不會有問題,但是最近總覺得怪,檔案還沒被關閉就return回主程式 這樣真的不會造成記憶體的浪費嗎?有沒有人可以教我一下該怎麼去觀察記憶體使用狀況? 我在想是不是改成以下這種寫法比較好? int status=0; while(fscanf(fid_rd,"%s",&tmp)!=NULL){ if(strcmp("PASS",tmp)==0){ status=1; break; } } fclose(fid_rd); return status; 再麻煩高手解答了,感謝 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 150.116.208.71 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1701790992.A.67B.html

12/05 23:52, 11月前 , 1F
fd開了就要自己關,如果不持續跑可能就還好
12/05 23:52, 1F

12/06 00:38, 11月前 , 2F
回傳fd的同時,參數多個吃&status的ptr,決策權丟給caller
12/06 00:38, 2F

12/06 09:13, 11月前 , 3F
最終 process 結束後 OS 會幫你回收
12/06 09:13, 3F

12/06 09:13, 11月前 , 4F
只有在你自己這個 process 裡面浪費
12/06 09:13, 4F

12/06 10:12, 11月前 , 5F
可以先 fopen,改傳 FILE*,不要傳檔名讓sub_test()做fopen
12/06 10:12, 5F

12/06 10:12, 11月前 , 6F
sub_test 做完在 fclose
12/06 10:12, 6F

12/06 21:35, 11月前 , 7F
老師是不是教你if內只能寫一行?
12/06 21:35, 7F

12/06 21:39, 11月前 , 8F
我知道問題在哪了fclose(fid_rd);是不是只能出現一次?
12/06 21:39, 8F

12/07 22:57, 11月前 , 9F
嚴格說起來 fopen() 不檢查回傳值不是也該覺得怪?
12/07 22:57, 9F

12/08 13:21, 11月前 , 10F
記憶體不會浪費吧,file descriptor 會浪費
12/08 13:21, 10F

12/09 15:55, 11月前 , 11F
一直重複開檔不關的行為,程式跑久了就會吃系統可用的fd
12/09 15:55, 11F

12/09 15:56, 11月前 , 12F
系統會一堆靈異現象,直到你用lsof看才發現開了幾千個fd
12/09 15:56, 12F

12/09 23:31, 11月前 , 13F
你的想法是對的,fxxx系列函數一般的實作應該會有input
12/09 23:31, 13F

12/09 23:31, 11月前 , 14F
buffer,會佔掉heap memory,fclose完才會釋放掉
12/09 23:31, 14F

12/10 10:41, 11月前 , 15F
應該會先跳too many open files吧
12/10 10:41, 15F

12/25 22:50, 11月前 , 16F
12/25 22:50, 16F
文章代碼(AID): #1bRqKGPx (C_and_CPP)
文章代碼(AID): #1bRqKGPx (C_and_CPP)