fclose | 易学教程

What happens to FILE pointer after file is closed?

阅读更多关于 What happens to FILE pointer after file is closed?

I wish to know what happens to FILE pointer after the file is closed. Will it be NULL? Basically, I want to check if a file has already been closed before closing a file. For example as follows: FILE *f; if(f!=NULL) { fclose(f); } Can I do this or is there any other way to go about it? Since arguments are passed by value there is not way fclose could set your file pointer to NULL . Since fclose probably destroys the FILE you have to Manually set the file pointer to NULL after doing a fclose (won't work if you close it in a different function unles you use FILE ** ) Don't end up in a situation

fclose() causing segmentation fault

阅读更多关于 fclose() causing segmentation fault

I have a tab-delimited text file that I am parsing. Its first column contains strings of the format chrX , where X denotes a set of strings, e.g., "1", "2", ..., "X", "Y". These are each stored in a char* called chromosome , as the file is parsed. The text file is sorted on the first column lexicographically, i.e., I will have a number of rows starting with "chr1", and then "chr2", etc. At each "chrX" entry, I need to open another file that is associated with this entry: FILE *merbaseIn; // loop through rows... if (chromosome == NULL) openSourceFile(&chromosome, fieldArray[i], &merbaseIn,

Why glibc's fclose(NULL) cause segmentation fault instead of returning error?

阅读更多关于 Why glibc's fclose(NULL) cause segmentation fault instead of returning error?

According to man page fclose(3) : RETURN VALUE Upon successful completion 0 is returned. Otherwise, EOF is returned and the global variable errno is set to indicate the error. In either case any further access (including another call to fclose() ) to the stream results in undefined behavior. ERRORS EBADF The file descriptor underlying fp is not valid. The fclose() function may also fail and set errno for any of the errors specified for the routines close(2) , write(2) or fflush(3) . Of course fclose(NULL) should fail but I expect that it to return with an errno normally instead of dying by

fclose()/pclose() may block on some file pointers

阅读更多关于 fclose()/pclose() may block on some file pointers

问题 Calling fclose() here after dup() ing its file descriptor blocks until the child process has ended (presumably because the stream has ended). FILE *f = popen("./output", "r"); int d = dup(fileno(f)); fclose(f); However by manually performing the pipe() , fork() , execvp() of the popen() , and then dup() ing the pipe's read file descriptor, closing the original does not block. int p[2]; pipe(p); switch (fork()) { case 0: { char *argv[] = {"./output", NULL}; close(p[0]); dup2(p[1], 1); execvp(

How exactly does fopen(), fclose() work?

阅读更多关于 How exactly does fopen(), fclose() work?

问题 I was just wondering about the functions fopen, fclose, socket and closesocket. When calling fopen or opening a socket, what exactly is happening (especially memory wise)? Can opening files/sockets without closing them cause memory leaks? And third, how are sockets created and what do they look like memory wise? I'm also interrested in the role of the operating system (Windows) in reading the sockets and sending the data. 回答1: Disclaimer: I'm mostly unqualified to talk about this. It'd be

What happens if I don't call fclose() in a C program?

阅读更多关于 What happens if I don't call fclose() in a C program?

Firstly, I'm aware that opening a file with fopen() and not closing it is horribly irresponsible, and bad form. This is just sheer curiosity, so please humour me :) I know that if a C program opens a bunch of files and never closes any of them, eventually fopen() will start failing. Are there any other side effects that could cause problems outside the code itself? For instance, if I have a program that opens one file, and then exits without closing it, could that cause a problem for the person running the program? Would such a program leak anything (memory, file handles)? Could there be