fopen() vs. open()

[Grocery Clerk]

I know open() returns a file descriptor and fopen() returns a pointer
to FILE. The question is, when do I use fopen() and when do I use
open()? Could someone give me an example when to use one over the
other?

 

[Jack Klein]

I know open() returns a file descriptor and fopen() returns a pointer
to FILE. The question is, when do I use fopen() and when do I use
open()? Could someone give me an example when to use one over the
other?

fopen() and the type FILE * are part of the standard C library,
available on every hosted implementation.

open() and file descriptors are not part of standard C. They are
non-standard extensions provided by your system, as far as the C
language is concerned.

So if you want to write standard portable C code, use fopen().

 

[Keith Thompson]

I know open() returns a file descriptor and fopen() returns a pointer
to FILE. The question is, when do I use fopen() and when do I use
open()? Could someone give me an example when to use one over the
other?

Use fopen() when you want to write portable code. The open() function
is not defined in the C standard.

 

[Fredrik Tolf]

fopen() and the type FILE * are part of the standard C library,
available on every hosted implementation.

open() and file descriptors are not part of standard C. They are
non-standard extensions provided by your system, as far as the C
language is concerned.

So if you want to write standard portable C code, use fopen().

It is also worth noting that stdio FILEs, as returned by fopen(), are
(or can be) buffered. Thus, if you want buffered I/O, use fopen().

Fredrik Tolf

 

[Dan Pop]

It is also worth noting that stdio FILEs, as returned by fopen(), are
(or can be) buffered. Thus, if you want buffered I/O, use fopen().

Buffering is not the issue: files accessed with open() and friends are
buffered, too.

The real issue, apart from portability (open() and friends are actually
*very* portable, even if the standard doesn't guarantee it), is that,
on certain platforms, read() and write() are OS primitives and, therefore,
much more expensive than ordinary library calls. No big deal when used
with large data chunks, but using read() instead of getc() and write()
instead of putc() may destroy the program's performance. That's why
the <stdio.h> I/O routines add one *additional* layer of buffering.

Dan

 

[Kelsey Bjarnason]

[snips]

It is also worth noting that stdio FILEs, as returned by fopen(), are
(or can be) buffered. Thus, if you want buffered I/O, use fopen().

Not sure how that's relevant to the post above: since read and open aren't
part of the C standard, as far as C is concerned, they may well be
buffered I/O routines.

 

[Fredrik Tolf]

Buffering is not the issue: files accessed with open() and friends are
buffered, too.

The real issue, apart from portability (open() and friends are actually
*very* portable, even if the standard doesn't guarantee it), is that,
on certain platforms, read() and write() are OS primitives and, therefore,
much more expensive than ordinary library calls. No big deal when used
with large data chunks, but using read() instead of getc() and write()
instead of putc() may destroy the program's performance. That's why
the <stdio.h> I/O routines add one *additional* layer of buffering.

I know that buffering wasn't the issue -- I just thought I'd add it. I
realize that maybe I should have marked the message OT, though.

<OT>
Files opened with open() need not even necessarily be buffered,
regardless of whether they are syscalls -- It depends on the type of
file, the operating system and many other factors (it could be opened
with O_SYNC, on a filesystem mounted synchronously, be a terminal are
other device, or whatever).

Files opened with fopen(), however, are guaranteed to be buffered. Even
if they aren't buffered from the start, they can always be made
buffered.
</OT>

Fredrik Tolf

 

[Martin Ambuhl]

I know open() returns a file descriptor and fopen() returns a pointer
to FILE. The question is, when do I use fopen() and when do I use
open()? Could someone give me an example when to use one over the
other?

If you want to use standard C, use fopen(). There is no open() in the C
standard libraries. A newsgroup for your implementation or platform (or
a similar one supporting POSIX) might be a place to ask; this newsgroup
is for C questions.

 

[Dan Pop]

I know that buffering wasn't the issue -- I just thought I'd add it. I
realize that maybe I should have marked the message OT, though.

<OT>
Files opened with open() need not even necessarily be buffered,
regardless of whether they are syscalls -- It depends on the type of
file, the operating system and many other factors (it could be opened
with O_SYNC, on a filesystem mounted synchronously, be a terminal are
other device, or whatever).

Files opened with fopen(), however, are guaranteed to be buffered. Even
if they aren't buffered from the start, they can always be made
buffered.
</OT>

You're mixing up two layers of buffering: the one performed by the OS and
the one performed by <stdio.h> routines. Both count as buffering and both
can be enabled or disabled by the application, so I fail to see your
point.

Dan

 

[Fredrik Tolf]

You're mixing up two layers of buffering: the one performed by the OS and
the one performed by <stdio.h> routines. Both count as buffering and both
can be enabled or disabled by the application, so I fail to see your
point.

My point is that not all file descriptors can be buffered. Take terminal
or device I/O files, for example. That's my main point -- not all file
descriptors can be buffered. Stdio FILEs, however, can _always_ be
buffered.

 

[Dan Pop]

My point is that not all file descriptors can be buffered.

Then, your point is wrong.

Take terminal or device I/O files, for example.

They are buffered on my system, by default. E.g. removing the <stdio.h>
buffering on stdin (when connected to the terminal) has no effect, because
/dev/tty itself is line buffered, by default, at the OS level. I need to
change the buffering at this layer (using the <termios.h> interface)
if I want to get characters as soon as they are available, without
waiting for the user to press the Return/Enter key.

That's my main point -- not all file descriptors can be buffered.

Again, your point is wrong.

Stdio FILEs, however, can _always_ be buffered.

At a *different* layer, but this point seems to be too subtle for you.

Dan