-2

I have a question about FILE pointer operations in C; specifically, what happens when a command uses a closed file pointer.

Here is an example

FILE *fp1;
fp1 = fopen(file1,"r");
function1(fp1);
fclose(fp1);

FILE *fp2;
fp2 = fopen(file2,"r");
function2(fp1);      
fclose(fp2);

So what I found out is: since fp1 is closed, the code will automatically use the next open/linked pointer, in this case, is fp2. However, if the code is changed to 

FILE *fp1;
//fp1 = fopen(file1,"r");
//function1(fp1);
fclose(fp1);

FILE *fp2;
fp2 = fopen(file2,"r");
function2(fp1);      
fclose(fp2);

There will be segmentation fault. In addition, if there is an open file pointer fp3 in between fp1 and fp2, and fp1 is closed, the code will select fp3.

I am not sure this way of C dealing with deleted/closed FILE pointer is just a language specific fail-safe mechanism, or has something to do with the way these pointer variables lie in the physical memory? And what happens to these pointers after fclose()?

eg. If all FILE pointers are stored consecutively in memory and fclose only delete the memory the current pointer uses, then C will access the next available memory chunk to get the value.

PS: I am not sure if all FILE pointers are stored separately from other variables so I tested it by inserting a new int pointer assignment between the above fp1 and fp2 segments. It does not interfere with the FILE pointer "inherit" process. So probably the FILE pointers are stored separately?

eg. However, if flcose() make the current pointer a NULL pointer, should any command using the current pointer just produce an error?

Thank you!

CrazyFrog
  • 323
  • 5
  • 19
  • 2
    Using a closed `FILE*` is invalid and results in undefined behavior. If the call works, it's just by pure luck. –  Nov 13 '14 at 02:17
  • It may be a matter of coincidence or luck that the system is reusing `FILE*` values. Do not rely on this. You can lower the chances of this sort of thing happening and/or detect it sooner by minimizing variable scope and setting pointers to NULL when you are done with them. – nobody Nov 13 '14 at 02:17
  • Thank you both for your comments! I understand that the behaviour I observed is pure luck. I am just trying to clear out how memory is allocated to pointer variables :) – CrazyFrog Nov 20 '14 at 16:34

2 Answers2

4

Performing any action on the FILE pointed to by fp1 after calling fclose on it results in Undefined Behavior. In all likelihood, what's happening is that, since the memory pointed to by fp1 was freed for reuse, fp2 happens to have the same value that fp1 had prior to it becoming invalid, and thus when the implementation dereferences fp1, it accesses the memory pointed to by fp2.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
1

If you are going to open something and assign it to a pointer, the very next thing that you should do is verify that this was successful. Aside from this, here is the explanation of the behavior that you are seeing based on the code that you have posted:

First, it is not "automatically using" the next file pointer. When you close fp1 and then immediately fopen and assign it to fp2, the dynamic memory module is simply reusing that same chunk of memory. You aren't guaranteed this behavior, but since your code is so trivial it is almost guaranteed to happen regardless of the memory management library in use.

Second, when you fclose(fp1) without opening it, the system isn't generating a segmentation fault... You are. You are effectively causing a free() call to occur on something that was never allocated.

David Hoelzer
  • 15,862
  • 4
  • 48
  • 67
  • Let's not discourage or belittle beginning programmers. You may have an opinion about the quality of the code, but it does not belong in you answer. – David C. Rankin Nov 13 '14 at 02:27
  • That's fair. I'll edit it. But bad coding practice needs to be pointed out or you won't fix it. – David Hoelzer Nov 13 '14 at 02:28
  • I have to remind myself of that as well. We are here to be constructive and help. – David C. Rankin Nov 13 '14 at 02:28
  • Thank you both very much for your comments and criticism! I am absolutely glad always to hear them! So I guess the behaviour I found is pure luck. But just a future question, when C create a pointer to an object, will the pointers always be put in a separate chunk of memory space aside from other variables? – CrazyFrog Nov 20 '14 at 16:31
  • Yes... ish. Pointers themselves are most likely local variables. These appear in one region of memory. What they point to is almost always dynamically allocated memory which would be from the Heap. Of course, you could assign a pointer to point at something that was statically allocated which would put them both into the same region and you could allocate a pointer in dynamic memory which would move the pointer out into the heap. An example of this second would be the internal pointers in a node of a binary tree, for example. – David Hoelzer Nov 20 '14 at 23:48