3

Suppose that we have opened a file using fopen() in C and we unintentionally forget to close it using fclose() then what could be the consequences of it? Also what are the solutions to it if we are not provided with the source code but only executable?

  • If you suspect a problem in an executable file you need to fix it in the source code. If you don't have the source code refer it back to the developer. –  Aug 13 '14 at 01:43
  • If that fopen was done in *read-only* mode then, while this is very poor coding quality, at least it will not cause any issues with data in the file. But if that fopen was done using a *write* mode you now have a very good chance of corrupting the data in that file. – jussij Aug 13 '14 at 01:46

3 Answers3

8

The consequences are that a file descriptor is "leaked". The operating system uses some descriptor, and has some resources associated with that open file. If you fopen and don't close, then that descriptor won't be cleaned up, and will persist until the program closes.

This problem is compounded if the file can potentially be opened multiple times. As the program runs more and more descriptors will be leaked, until eventually the operating system either refuses or is unable to create another descriptor, in which case the call to fopen fails.

If you are only provided with the executable, not the source code, your options are very limited. At that point you'd have to either try decompiling or rewriting the assembly by hand, neither of which are attractive options.

The correct thing to do is file a bug report, and then get an updated/fixed version.

Robert Allan Hennigan Leahy
  • 6,478
  • 28
  • 45
  • Will the system eventually refuse because of memory constraints or is there another reason? For example, assuming we continuously `fopen`-ed and we had infinite memory, would the system never refuse to open the file? – JoeVictor Jul 10 '18 at 16:48
2

If there are a lot of files open but not closed properly, the program will eventually run out of file handles and/or memory space and crash.

Suggest you engage your developer to update their code.

rurouni88
  • 1,165
  • 5
  • 10
0

The consequences is implementation dependent based on the fclose / fopen and associated functions -- they are buffered input/output functions. So things write are written to a "file" is in fact first written to an internal buffer -- the buffer is only flushed to output when the code "feels like it" -- that could be every line, every write of every full block depending on the smartness of the implementation.

The fopen will most likely use open to get an actual file descriptor to the operating system -- on most systems (Linux, Windows etc) the os file descriptor will be closed by the OS when the process terminates -- however if the program does not terminates, the os file descriptor will leak and you will eventually run out of file descriptors and die.

Some standard may mandate a specific behavior when the program terminates either cleanly or through a crash, but the fact is that you cannot reply in this as not all implementations may follow this.

So your risk is that you will loose some of the data which you program believed that it had written -- that would be the data which was sitting in the internal buffer but never flushed -- or you may run out of file descriptors and die.

So, fix the code.

Soren
  • 14,402
  • 4
  • 41
  • 67