Re: OT: Re: fopen() vs. open()
From: Dan Pop (Dan.Pop_at_cern.ch)
Date: 09/30/04
- Next message: Malcolm: "Re: ++i vs i++"
- Next in thread: Fredrik Tolf: "Re: OT: Re: fopen() vs. open()"
- Reply: Fredrik Tolf: "Re: OT: Re: fopen() vs. open()"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 30 Sep 2004 19:08:30 GMT
In <1096565628.10848.86.camel@pc7.dolda2000.com> Fredrik Tolf <fredrik@dolda2000.com> writes:
>On Thu, 2004-09-30 at 15:20 +0000, Dan Pop wrote:
>> In <1096552161.10848.74.camel@pc7.dolda2000.com> Fredrik Tolf <fredrik@dolda2000.com> writes:
>>
>> >On Thu, 2004-09-30 at 00:11 -0500, Jack Klein wrote:
>> >> On 29 Sep 2004 21:33:57 -0700, cdalten@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: Dan.Pop@ifh.de
Currently looking for a job in the European Union
- Next message: Malcolm: "Re: ++i vs i++"
- Next in thread: Fredrik Tolf: "Re: OT: Re: fopen() vs. open()"
- Reply: Fredrik Tolf: "Re: OT: Re: fopen() vs. open()"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
