235

Is there any reason (other than syntactic ones) that you'd want to use 

FILE *fdopen(int fd, const char *mode);

or

FILE *fopen(const char *path, const char *mode);

instead of 

int open(const char *pathname, int flags, mode_t mode);

when using C in a Linux environment?

tshepang
  • 10,772
  • 21
  • 84
  • 127
LJM
  • 5,654
  • 6
  • 25
  • 27
  • Did you mean `fdopen` and `open` or `fopen` and `open`? – user7116 Nov 01 '09 at 21:53
  • Don't you mean fopen, not fdopen? – Omnifarious Nov 01 '09 at 21:53
  • 9
    `fopen` is part of standard C library, `open` is not. Use `fopen` when writing portable code. – Aziz Nov 01 '09 at 21:53
  • Yes, I meant fopen. I just updated it, but I think the same principle applies. – LJM Nov 01 '09 at 21:54
  • 7
    @Aziz, `open` is a POSIX function though. – dreamlax Nov 01 '09 at 21:55
  • Amusing tidbit: this just came up when I [searched for "open function C"](http://social.msdn.microsoft.com/Search/en-US?query=open%20function%20C&beta=0&ac=8) on the MSDN site :-) – SamB May 05 '11 at 15:05
  • If you have a file descriptor created by `pipe()` — or perhaps `socket()`, though that's less likely — and you want to use standard `FILE *` I/O on it, then you need to use `fdopen()` to create the stream. There are also numerous options that can be specified with `open()` that cannot be specified with `fopen()` — perhaps most prominently `O_EXCL`, but there are certainly others too — and those might be good reasons for using `open()` (instead of `fopen()`) followed by `fdopen()`. – Jonathan Leffler Mar 21 '19 at 04:24
  • fopen uses open too: FILE* fopen(const char* file, const char* mode) {... int fd = open(file, mode_flags, DEFFILEMODE);...FILE* fp = __fopen(fd, flags);...return fp;} where __fopen creates a FILE object using __sfp() and put the fd in it. BTW does anybody know where is __sfp()? – jw_ Dec 07 '19 at 02:06

11 Answers11

254

First, there is no particularly good reason to use fdopen if fopen is an option and open is the other possible choice. You shouldn't have used open to open the file in the first place if you want a FILE *. So including fdopen in that list is incorrect and confusing because it isn't very much like the others. I will now proceed to ignore it because the important distinction here is between a C standard FILE * and an OS-specific file descriptor.

There are four main reasons to use fopen instead of open.

  1. fopen provides you with buffering IO that may turn out to be a lot faster than what you're doing with open.
  2. fopen does line ending translation if the file is not opened in binary mode, which can be very helpful if your program is ever ported to a non-Unix environment (though the world appears to be converging on LF-only (except IETF text-based networking protocols like SMTP and HTTP and such)).
  3. A FILE * gives you the ability to use fscanf and other stdio functions.
  4. Your code may someday need to be ported to some other platform that only supports ANSI C and does not support the open function.

In my opinion the line ending translation more often gets in your way than helps you, and the parsing of fscanf is so weak that you inevitably end up tossing it out in favor of something more useful.

And most platforms that support C have an open function.

That leaves the buffering question. In places where you are mainly reading or writing a file sequentially, the buffering support is really helpful and a big speed improvement. But it can lead to some interesting problems in which data does not end up in the file when you expect it to be there. You have to remember to fclose or fflush at the appropriate times.

If you're doing seeks (aka fsetpos or fseek the second of which is slightly trickier to use in a standards compliant way), the usefulness of buffering quickly goes down.

Of course, my bias is that I tend to work with sockets a whole lot, and there the fact that you really want to be doing non-blocking IO (which FILE * totally fails to support in any reasonable way) with no buffering at all and often have complex parsing requirements really color my perceptions.

Omnifarious
  • 50,447
  • 15
  • 117
  • 181
  • 4
    I'm not going to question your experiences, but I'd love to hear you elaborate a bit on this. For what kind of applications do you feel that the built-in buffering gets in the way? What exactly is the problem? – Emil H Nov 01 '09 at 22:04
  • 1
    Didn't see the last paragraph. Valid point, IMHO. As far as I can tell the question was about file IO, though. – Emil H Nov 01 '09 at 22:06
  • Almost any program that does not stream IO, where you end up doing seeks into the middle of the file. I should update my response to clarify. – Omnifarious Nov 01 '09 at 22:08
  • So would it be correct to conclude that 'fgets' would block the thread until it reads a full line. And that non-buffered IO (such as read) would inherently not block the thread because they have no buffer to hold the data? – LJM Nov 01 '09 at 22:14
  • @L. Moser: No. The blocking and buffering are not strongly coupled. You would have to set the file descriptor to `O_NONBLOCK` with `fcntl` and and the `EAGAIN` error when `read` failed in order to avoid blocking a thread with `read`. – Omnifarious Nov 01 '09 at 22:17
  • 8
    To clarify when buffering gets in the way. It's when you use seek. The following read with whatever command (`fgets`, `fgetc`, `fscanf`, `fread`) , will always read the whole size of the buffer (4K, 8K or whatever you set). By using the direct I/O you can avoid that. In that case it's even better to use `pread` instead of a seek/read pair (1 syscall instead of 2). – Patrick Schlüter May 05 '10 at 13:16
  • @LJM - To clarify further on that somewhat muddled answer from 2 years ago... :-) Yes, fgets will do exactly that. And there is no reasonable way for it not to. But just using `read` does not magically get you non-blocking IO. You have to set the O_NONBLOCK flag on the descriptor somehow, and then properly handle the EAGAIN condition/error on `read`. The latter, in particular, is non-trivial since you frequently need to remember some sort of parser state until there is data available to `read`. Some people think you should just give up and use cheap threads that block. – Omnifarious Aug 14 '12 at 04:13
  • 2
    Handling interrupted `read()` and `write()` calls is a convenient fifth reason to use the libc family of functions. – nccc Aug 26 '12 at 21:54
  • What about opening a device file and send an ioctl? Can I use `fopen` which returns `FILE*` where ioctl() expects and `int fd`? – m-ric Sep 28 '12 at 15:37
  • 3
    @m-ric: Well, that's a somewhat unrelated question, but yes. All platforms that support `ioctl` also support the `fileno` call which takes a `FILE *` and returns a number that can be used in an `ioctl` call. Be careful though. `FILE *` related calls may interact surprisingly with using `ioctl` to change something about the underlying file descriptor. – Omnifarious Sep 28 '12 at 15:53
  • I own a map rendering library (CartoType) which does its own buffering. I experimented with moving from high-level to low-level io (from fopen to open, etc.) and benchmarked the performance before and after. Low-level io was better, but only by 3%. I have not yet decided whether a 3% improvement is worth it. Probably yes, because I can encapsulate the platform-dependent code. – Graham Asher Apr 12 '15 at 15:45
  • The second reason is rather doubtful because: [For portability, it is strongly recommended that you always use the 'b' flag when opening files with fopen().](http://php.net/manual/en/function.fopen.php) I strongly believe that the same code should produce binary equal files regardless of the operation system on which it is executed. Otherwise this code is not truly portable. And I do not see any problems when using Unix line endings everywhere because all significant applications on Windows (even Notepad [since the last year](http://archive.li/Dskp0)) are support them. – tav Jan 27 '19 at 07:41
  • @tav - I happen to know that there is some pressure from the top at Microsoft to abandon CRLF line endings in Microsoft products in general. So, I expect them to slowly fade out. – Omnifarious Jan 27 '19 at 17:11
59

open() is a low-level os call. fdopen() converts an os-level file descriptor to the higher-level FILE-abstraction of the C language. fopen() calls open() in the background and gives you a FILE-pointer directly.

There are several advantages to using FILE-objects rather raw file descriptors, which includes greater ease of usage but also other technical advantages such as built-in buffering. Especially the buffering generally results in a sizeable performance advantage.

Emil H
  • 37,947
  • 10
  • 72
  • 95
  • 3
    Are there any disadvantages to using the buffered 'f...' versions of open? – LJM Nov 01 '09 at 21:58
  • 6
    @L. Moser, yes, when you are already buffering the data, and hence the additional buffer adds unnecessary copying and memory overhead. – Michael Aaron Safyan Nov 02 '09 at 01:41
  • 6
    actually there are other disadvantages. `fopen()` does not provide the same level of control when opening files, for example create permissions, sharing modes, and more. typically `open()` and variants provide much more control, close to what the operating system actually provides – Matt Joiner Nov 07 '09 at 11:54
  • 3
    There are also the extreme cases where you `mmap` the file and do changes with normal I/O (as incredible as it sounds we do actually that in our project and for real good reasons), buffering would be in the way. – Patrick Schlüter May 05 '10 at 13:20
  • You also may want to use other system functions, like using open() for preloading files into page cache via readahead(). I guess rule of thumb is "use fopen unless you absolutely need open()", open() actually lets you do fancy stuff (setting/not setting O_ATIME and similar). – Tomas Pruzina May 14 '13 at 04:11
39

fopen vs open in C

1) fopen is a library function while open is a system call.

2) fopen provides buffered IO which is faster compare to open which is non buffered.

3) fopen is portable while open not portable (open is environment specific).

4) fopen returns a pointer to a FILE structure(FILE *); open returns an integer that identifies the file.

5) A FILE * gives you the ability to use fscanf and other stdio functions.

Yogeesh H T
  • 2,093
  • 18
  • 17
14

Unless you're part of the 0.1% of applications where using open is an actual performance benefit, there really is no good reason not to use fopen. As far as fdopen is concerned, if you aren't playing with file descriptors, you don't need that call.

Stick with fopen and its family of methods (fwrite, fread, fprintf, et al) and you'll be very satisfied. Just as importantly, other programmers will be satisfied with your code.

chwarr
  • 5,726
  • 1
  • 24
  • 52
user7116
  • 60,025
  • 16
  • 134
  • 166
11

If you have a FILE *, you can use functions like fscanf, fprintf and fgets etc. If you have just the file descriptor, you have limited (but likely faster) input and output routines read, write etc.

dreamlax
  • 89,489
  • 28
  • 156
  • 207
7

Using open, read, write means you have to worry about signal interaptions.

If the call was interrupted by a signal handler the functions will return -1 and set errno to EINTR.

So the proper way to close a file would be

while (retval = close(fd), retval == -1 && ernno == EINTR) ;
digy
  • 1,953
  • 3
  • 15
  • 14
  • 4
    For `close`, this depends on the operating system. It's incorrect to do the loop on Linux, AIX and some other operating systems. – strcat Dec 30 '13 at 22:29
  • In addition, using read and write will suffer the same issue, i.e., they can get interrupted by a signal before processing the input/output entirely and the programmer has to handle such situations, while fread and fwrite handle signal interruptions nicely. – Marcelo Jul 05 '18 at 20:55
6

open() is a system call and specific to Unix-based systems and it returns a file descriptor. You can write to a file descriptor using write() which is another system call.
fopen() is an ANSI C function call which returns a file pointer and it is portable to other OSes. We can write to a file pointer using fprintf.

In Unix:
You can get a file pointer from the file descriptor using: 

fP = fdopen(fD, "a");

You can get a file descriptor from the file pointer using: 

fD = fileno (fP);
Pang
  • 8,605
  • 144
  • 77
  • 113
Arun Chettoor
  • 861
  • 1
  • 9
  • 16
4

open() will be called at the end of each of the fopen() family functions. open() is a system call and fopen() are provided by libraries as a wrapper functions for user easy of use

theadnangondal
  • 1,326
  • 3
  • 11
  • 27
2

Depends also on what flags are required to open. With respect to usage for writing and reading (and portability) f* should be used, as argued above.

But if basically want to specify more than standard flags (like rw and append flags), you will have to use a platform specific API (like POSIX open) or a library that abstracts these details. The C-standard does not have any such flags.

For example you might want to open a file, only if it exits. If you don't specify the create flag the file must exist. If you add exclusive to create, it will only create the file if it does not exist. There are many more.

For example on Linux systems there is a LED interface exposed through sysfs. It exposes the brightness of the led through a file. Writing or reading a number as a string ranging from 0-255. Of course you don't want to create that file and only write to it if it exists. The cool thing now: Use fdopen to read/write this file using the standard calls.

Ritualmaster
  • 196
  • 8
2

I changed to open() from fopen() for my application, because fopen was causing double reads every time I ran fopen fgetc . Double reads were disruptive of what I was trying to accomplish. open() just seems to do what you ask of it.

Ersatz Splatt
  • 21
  • 1
-1

opening a file using fopen
before we can read(or write) information from (to) a file on a disk we must open the file. to open the file we have called the function fopen. 

1.firstly it searches on the disk the file to be opened.
2.then it loads the file from the disk into a place in memory called buffer.
3.it sets up a character pointer that points to the first character of the buffer.

this the way of behaviour of fopen function
there are some causes while buffering process,it may timedout. so while comparing fopen(high level i/o) to open (low level i/o) system call , and it is a faster more appropriate than fopen.

prashad
  • 109
  • 2
  • 15