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]

On 29 Sep 2004 21:33:57 -0700, cd*****@yahoo.com (Grocery Clerk) wrote
in comp.lang.c:

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().

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Keith Thompson]

cd*****@yahoo.com (Grocery Clerk) writes:

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Fredrik Tolf]

On Thu, 2004-09-30 at 00:11 -0500, Jack Klein wrote:

On 29 Sep 2004 21:33:57 -0700, cd*****@yahoo.com (Grocery Clerk) wrote
in comp.lang.c:

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().

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]

In <10***********************@pc7.dolda2000.com> Fredrik Tolf <fr*****@dolda2000.com> writes:

On Thu, 2004-09-30 at 00:11 -0500, Jack Klein wrote:

On 29 Sep 2004 21:33:57 -0700, cd*****@yahoo.com (Grocery Clerk) wrote
in comp.lang.c:

> 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().

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Kelsey Bjarnason]

[snips]

On Thu, 30 Sep 2004 15:49:21 +0200, Fredrik Tolf wrote:

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().

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]

On Thu, 2004-09-30 at 15:20 +0000, Dan Pop wrote:

In <10***********************@pc7.dolda2000.com> Fredrik Tolf <fr*****@dolda2000.com> writes:

On Thu, 2004-09-30 at 00:11 -0500, Jack Klein wrote:

On 29 Sep 2004 21:33:57 -0700, cd*****@yahoo.com (Grocery Clerk) wrote
in comp.lang.c:

> 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().

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.

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

[Dan Pop]

In <10***********************@pc7.dolda2000.com> Fredrik Tolf <fr*****@dolda2000.com> writes:

On Thu, 2004-09-30 at 15:20 +0000, Dan Pop wrote:

In <10***********************@pc7.dolda2000.com> Fredrik Tolf <fr*****@dolda2000.com> writes:

>On Thu, 2004-09-30 at 00:11 -0500, Jack Klein wrote:
>> On 29 Sep 2004 21:33:57 -0700, cd*****@yahoo.com (Grocery Clerk) wrote
>> in comp.lang.c:
>>
>> > 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().
>
>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.

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Martin Ambuhl]

Grocery Clerk wrote:

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.

[Fredrik Tolf]

On Thu, 2004-09-30 at 19:08 +0000, Dan Pop wrote:

In <10***********************@pc7.dolda2000.com> Fredrik Tolf <fr*****@dolda2000.com> writes:

On Thu, 2004-09-30 at 15:20 +0000, Dan Pop wrote:

In <10***********************@pc7.dolda2000.com> Fredrik Tolf <fr*****@dolda2000.com> writes:

>On Thu, 2004-09-30 at 00:11 -0500, Jack Klein wrote:
>> On 29 Sep 2004 21:33:57 -0700, cd*****@yahoo.com (Grocery Clerk) wrote
>> in comp.lang.c:
>>
>> > 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().
>
>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.

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.

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]

In <10***********************@pc7.dolda2000.com> Fredrik Tolf <fr*****@dolda2000.com> writes:

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union