🚀 go-pugleaf

natewild@mbnet.mb.ca (Nathan T. Wild) writes:

>In C, why would one use open and DOS int handles rather than fopen and
>stdio file handles?

The only reason I know of is UNIX portability.  Whenever I run across a
unix program that uses the old-style open instead of fopen I usually
end up rewriting it anyway though; I've had so many problems with
the unix-style stuff I just rather would deal with the ANSI style.

David
>Is there some speed advantage or differnet functionality?

>     

>|--------------------------------------------------------------------|
>| ooooO (``)   (``) Ooooo | Nathan T. Wild                           | 
>| (   ) )  (   )  ( (   ) | natewild@mbnet.mb.ca                     |
>| )  (  (   ) (   ) )  (  | ftp://ftp.mbnet.mb.ca/pub/natewild       |
>| (__)  ooooO Ooooo (__)  | http://www.mbnet.mb.ca/~natewild         |
>|--------------------------------------------------------------------|

In article <uEYFxc9nX8WX083yn@mbnet.mb.ca>,
Nathan T. Wild <natewild@mbnet.mb.ca> wrote:

>In C, why would one use open and DOS int handles rather than fopen and
>stdio file handles?
>
>Is there some speed advantage or differnet functionality?

open() is for raw I/O.  You use read(), write(), lseek(), ltell()

fopen() is for buffered I/O.  You can use fread(), fscanf(), fgets(),
getchar(), putchar, fprint(), fwrite(), fseek(), ftell(), etc.

For certain applications, you can get away without buffering.  But
often it is easier to do the programming if you don't have to worry
about unneeded system calls and buffering gives you that.

Raw I/O is faster if you are, for instance, sucking the entire contents
of a file into memory at once.

Buffered I/O tends to automatically include parts of the standard C
library that you may not need (*printf* stuff).

It depends on your goal.  And usually the reasons for using one or the
other are operating system independent.

-- Harold

sherlock@micronet.fr wrote:
>natewild@mbnet.mb.ca (Nathan T. Wild) wrote:
>
>>In C, why would one use open and DOS int handles rather than fopen and
>>stdio file handles?
>
>>Is there some speed advantage or differnet functionality?
>
>>     
>
>
>because files opened using open and DOS files handles can be read and
>write at the same time, while stdio files can't.
Hey, I didn't know that...

ANSI C says: 
ANSI C requires that a file positioning function intervene between output and
input, unless an input operation encounters end-of-file.

So according to this, one can actualy read and write from one file with the
same
FILE*. You open the open like `fopen("Filename", "r+")'.

>
>suppose you have a database file, with fixed length fields.
>low level functions(open...) enable the writing of some records and
>the reading of other without closing the file.

As stated above, high level functions (stdio functions) to it too.

>
>

Regards,
	Guus Leeuw jr

natewild@mbnet.mb.ca (Nathan T. Wild) wrote:

>In C, why would one use open and DOS int handles rather than fopen and
>stdio file handles?

>Is there some speed advantage or differnet functionality?

>     

>|--------------------------------------------------------------------|
>| ooooO (``)   (``) Ooooo | Nathan T. Wild                           | 
>| (   ) )  (   )  ( (   ) | natewild@mbnet.mb.ca                     |
>| )  (  (   ) (   ) )  (  | ftp://ftp.mbnet.mb.ca/pub/natewild       |
>| (__)  ooooO Ooooo (__)  | http://www.mbnet.mb.ca/~natewild         |
>|--------------------------------------------------------------------|


because files opened using open and DOS files handles can be read and
write at the same time, while stdio files can't.

suppose you have a database file, with fixed length fields.
low level functions(open...) enable the writing of some records and
the reading of other without closing the file.

In article <4f8qbg$549@chleuasme.francenet.fr>,
sherlock@micronet.fr wrote:

 > natewild@mbnet.mb.ca (Nathan T. Wild) wrote:

 > >In C, why would one use open and DOS int handles rather than fopen and
 > >stdio file handles?

 > because files opened using open and DOS files handles can be read and
 > write at the same time, while stdio files can't.

 Huh? Run that by me again. fopen can open a file for both
 read and write access or just read or just write access.
 
 DOS has nothing to do with permitting read, write, or read/write access,
 that is dependant on the hardware only. Using _dos_open
 returns the dos file handle which can be used with DOS interrupt services,
 this permits you to truncate a file if you wish. FILE is a
 structure about the file it is associated with and the buffer it uses.
 DOS doesn't give buffer info even if your using a buffer.
 
 > suppose you have a database file, with fixed length fields.
 > low level functions(open...) enable the writing of some records and
 > the reading of other without closing the file.

 suppose you just use "r+" for the access specifier with fopen().

In <4f8bev$6tr@hermes.louisville.edu> gclind01@starbase.spd.louisville.edu 
(George C. Lindauer) wrote:

>natewild@mbnet.mb.ca (Nathan T. Wild) writes:
>
>>In C, why would one use open and DOS int handles rather than fopen and
>>stdio file handles?
>
>The only reason I know of is UNIX portability.  Whenever I run across a
>unix program that uses the old-style open instead of fopen I usually
>end up rewriting it anyway though; I've had so many problems with
>the unix-style stuff I just rather would deal with the ANSI style.
>
>David
>>Is there some speed advantage or differnet functionality?

fopen() is mostly buffered, open() is, I believe, not. open() also gives some 
extra possible flags for sharing options. I use fopen() without problems. 
Besides, it's ANSI, and I program multiple programs and sometimes share 
modules that I'd have to check and redesign when switching from fopen to the 
local open command.

--
Ruud van Gaal
MarketGraph Visual Automation
E-Mail                : rvg@marketgraph.xs4all.nl
DoomShell 4.5 homepage: http://www.xs4all.nl/~jwkorver
"...Works fascinates me. I could sit and watch it for hours..."

In article <4f8qf1$h3b@ssbunews.ih.att.com> bamford@marconi.ih.att.com
(Harold E. Bamford) writes: 
   >In C, why would one use open and DOS int handles rather than fopen and
   >stdio file handles?
   >
   >Is there some speed advantage or differnet functionality?

   open() is for raw I/O.  You use read(), write(), lseek(), ltell()

   fopen() is for buffered I/O.  You can use fread(), fscanf(), fgets(),
   getchar(), putchar, fprint(), fwrite(), fseek(), ftell(), etc.
                       ^^^^^^???

You can specify that fopen etc. should not buffer at the level of the
C library. Whether there are further buffers up or down stream is an
OS issue.

   For certain applications, you can get away without buffering.  But
   often it is easier to do the programming if you don't have to worry
   about unneeded system calls and buffering gives you that.

   Raw I/O is faster if you are, for instance, sucking the entire contents
   of a file into memory at once.

   Buffered I/O tends to automatically include parts of the standard C
   library that you may not need (*printf* stuff).

Why?

   It depends on your goal.  And usually the reasons for using one or the
   other are operating system independent.

And, very importantly, fopen etc. are defined in the C standard, and
hence, code using it is maximally portable. open and its relatives are
are not defined by the C standard. (They are defined by other
standards, but that is a different issue.)

Cheers
Tanmoy
--
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]

In <4fbfno$7f@noc.tor.hookup.net> Rajendra_Singh@msn.com (Rajendra Singh) writes:

>gclind01@starbase.spd.louisville.edu (George C. Lindauer) wrote:
>
>>The only reason I know of is UNIX portability.  Whenever I run across a
>>unix program that uses the old-style open instead of fopen I usually
>>end up rewriting it anyway though; I've had so many problems with
>>the unix-style stuff I just rather would deal with the ANSI style.
>
>That's incorrect.  fopen() is used for buffered I/O!  open() is not a
>UNIX specific function nor is it non-ANSI!

That's incorrect.  open() is a Unix-specific function (even if it was
emulated on other systems) and it IS non-ANSI!

BTW, in Unix both open() and fopen() are used for buffered I/O!  fopen()
adds an _additional_ level of buffering in order to minimize the number 
of read/write system calls.  The kernel is doing its own buffering
for read/write operations.

Dan
--
Dan Pop
CERN, CN Division
Email: danpop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

gclind01@starbase.spd.louisville.edu (George C. Lindauer) wrote:

>The only reason I know of is UNIX portability.  Whenever I run across a
>unix program that uses the old-style open instead of fopen I usually
>end up rewriting it anyway though; I've had so many problems with
>the unix-style stuff I just rather would deal with the ANSI style.

That's incorrect.  fopen() is used for buffered I/O!  open() is not a
UNIX specific function nor is it non-ANSI!
---
Rajendra Singh, B. Sc. (Rajendra_Singh@msn.com)
"What is understood need not be discussed." - Loren Adams

Rajendra Singh <Rajendra_Singh@msn.com> wrote:
|> That's incorrect.  fopen() is used for buffered I/O!  open() is not a
|> UNIX specific function nor is it non-ANSI!

Here's some logic:

If open() is ANSI then all ANSI C compilers must have it.
There exists an ANSI C compiler that does not have open().
Therefore, open() is a non-ANSI C function.
-- 
"If it wasn't for C, we would be using BASI, PASAL, and OBOL."

Jonas J. Schlein  (schlein@gl.umbc.edu)

In <4fd7st$kcm@umbc9.umbc.edu> schlein@umbc.edu (Jonas J. Schlein) wrote:

>Here's some logic:
>
>If open() is ANSI then all ANSI C compilers must have it.
>There exists an ANSI C compiler that does not have open().
>Therefore, open() is a non-ANSI C function.

Or the ANSI C compiler has a bug. I prefer:
If open() is ANSI then all ANSI C compilers must have it.
There exists an ANSI standard that does not have open().
Therefore, open() is a non-ANSI C function.
:) waste of bandwidth, I presume...

--
Ruud van Gaal
MarketGraph Visual Automation
E-Mail                : rvg@marketgraph.xs4all.nl
DoomShell 4.5 homepage: http://www.xs4all.nl/~jwkorver
"...Works fascinates me. I could sit and watch it for hours..."

In article <4f8bev$6tr@hermes.louisville.edu>,
George C. Lindauer <gclind01@starbase.spd.louisville.edu> wrote:
 >natewild@mbnet.mb.ca (Nathan T. Wild) writes:
 >
 >>In C, why would one use open and DOS int handles rather than fopen and
 >>stdio file handles?
 >
 >The only reason I know of is UNIX portability.  Whenever I run across a
 >unix program that uses the old-style open instead of fopen I usually

There is nothing "old-style" about open(). It is a system call whereas fopen is
a standard C library function. The open() function is typically a  stub which
calls the operating system's open function directly. The fopen() library
routine uses open(), and stores the returned file descriptor inside the FILE
structure.

 >end up rewriting it anyway though; I've had so many problems with
 >the unix-style stuff I just rather would deal with the ANSI style.

The "ANSI style" still calls the "unix-style" stuff, except everything is
bounced through extra buffers. The standard library functions are for
programmer convenience; that's why UNIX evolved them. But it's not a case of
one replacing the other.
-- 

In article <4f8qf1$h3b@ssbunews.ih.att.com>,
Harold E. Bamford <bamford@marconi.ih.att.com> wrote:
>In article <uEYFxc9nX8WX083yn@mbnet.mb.ca>,
>Nathan T. Wild <natewild@mbnet.mb.ca> wrote:
>
>>In C, why would one use open and DOS int handles rather than fopen and
>>stdio file handles?
>>
>>Is there some speed advantage or differnet functionality?
>
>open() is for raw I/O.  You use read(), write(), lseek(), ltell()
>
>fopen() is for buffered I/O.  You can use fread(), fscanf(), fgets(),
>getchar(), putchar, fprint(), fwrite(), fseek(), ftell(), etc.

False. Both are buffered. The latter does an extra copy.

The justification for the extra buffering in the latter is that you can pump
data in smaller chunks _without_ causing needless context switches to the
kernel.

Calling fread() a byte at a time is much more efficient than calling read() a
byte at a time, because each call to read() causes a call to the kernel.

However, calling read() several kilobytes at a time is more efficient than
fread(), because it dispenses with an extra level of overhead.

>For certain applications, you can get away without buffering.  But
>often it is easier to do the programming if you don't have to worry
>about unneeded system calls and buffering gives you that.
       ^^^^^^^^^^^^^^^^^^^^^

Ah, now you are hitting much closer to the target!
-- 

natewild@mbnet.mb.ca (Nathan T. Wild) writes:
>
>In C, why would one use open and DOS int handles rather than fopen and
>stdio file handles?
>
>The only reason I know of is UNIX portability.  Whenever I run across a
>unix program that uses the old-style open instead of fopen I usually
>end up rewriting it anyway though; I've had so many problems with
>the unix-style stuff I just rather would deal with the ANSI style.
>
>David
>>>Is there some speed advantage or differnet functionality?
>
>fopen() is mostly buffered, open() is, I believe, not. open() also gives some 
>extra possible flags for sharing options. I use fopen() without problems. 
>Besides, it's ANSI, and I program multiple programs and sometimes share 
>modules that I'd have to check and redesign when switching from fopen to the 
>local open command.

The open() function and its ilk are normally referred to as the "low-level"
I/O package. fopen() is the "Buffered" or "Standard" I/O package. The 
strength of the low-level I/O functions is that they offer excellent control,
particularly when used with binary files. If you have a special I/O need, you
can use the low-level I/O routines to fashion the exact I/O package to fit
your needs. 
The standard I/O package is one such creation. It is designed to provide fast
buffered I/O, mostly for text situations. For a lot of applications, using the
standard I/O package is simpler and more effective than using simple low-level
output. The essential feature is its use of automatic buffering. Buffered 
I/O means reading and writing data in large chunks from a file to an array
and back. Reading and writing data in large chunks greatly speeds up the I/O
operations, while storing in an array allows access to the individual bytes.
The advantages of this approach should be apparent.
When fopen() is used, several things happen. The file, of course, is opened.
Second, an external character array is created to act as a buffer. The 
<stdio.h> file has this buffer set to a size of 512 bytes. Third, a structure
is created to contain information about the buffer and the file. When you 
call one of the functions from the standard I/O library, such as getc(),
the buffer is filled with data from the file. When getc() reaches the end of
the buffer, the buffer is automatically with the next block of data from the
file. You need not even be aware of the buffer, and you can program as if the
I/O functions worked directly with the file.
Technically, in DOS, all I/O is buffered since DOS itseld uses buffers
for disk I/O. This is a transparent function of the operating system and
has nothing to do with I/O packages included with C.

Hope this clarifies things.

-John Noland

In <4ftusv$181@newshost.cyberramp.net> sinan@cyberramp.net (John Noland) writes:

>The open() function and its ilk are normally referred to as the "low-level"
>I/O package. fopen() is the "Buffered" or "Standard" I/O package. The 
>strength of the low-level I/O functions is that they offer excellent control,
>particularly when used with binary files.

???  What can read/write do on a binary file that fread/fwrite cannot do?

>If you have a special I/O need, you
>can use the low-level I/O routines to fashion the exact I/O package to fit
>your needs. 

Same question as above.

>The standard I/O package is one such creation. It is designed to provide fast
>buffered I/O, mostly for text situations.
               ^^^^^^^^^^^^^^^^^^^^^^^^^^
???

>For a lot of applications, using the
>standard I/O package is simpler and more effective than using simple low-level
>output. The essential feature is its use of automatic buffering. Buffered 
>I/O means reading and writing data in large chunks from a file to an array
>and back. Reading and writing data in large chunks greatly speeds up the I/O
>operations, while storing in an array allows access to the individual bytes.
>The advantages of this approach should be apparent.

Except that you can read and write data in large chunks using stdio 
routines.  The impact of the extra level of buffering is insignificant.

>When fopen() is used, several things happen. The file, of course, is opened.
>Second, an external character array is created to act as a buffer. The 
><stdio.h> file has this buffer set to a size of 512 bytes.

To a default size of _minimum_ 256 bytes.  I'm typing this text on a
system which uses a default buffer size of 8192 bytes.  The size of the
buffer can be controlled by the programmer via the setvbuf function.

>Technically, in DOS, all I/O is buffered since DOS itseld uses buffers
>for disk I/O. 

The same applies to other operating systems (e.g. Unix) except that they
do a much better job at buffering I/O than MSDOS.

>Hope this clarifies things.

So many inaccurate statements don't clarify things.  On the contrary.

Dan
--
Dan Pop
CERN, CN Division
Email: danpop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

In <4fbfno$7f@noc.tor.hookup.net>, Rajendra_Singh@msn.com (Rajendra Singh) writes:

>That's incorrect.  fopen() is used for buffered I/O!  open() is not a
>UNIX specific function nor is it non-ANSI!

I'm afraid you're sadly mistaken.  open() is not ANSI.  It is a POSIX 1003.1
compliant function.  However, you are correct in stating that fopen()
provides for buffered file i/o.

+------------------------------------------------------+
!  OS/2         - The Champion of Operating Systems    !
!  Enitharmon/2 - A Powerful BBS Package               !
!  What a great pair!               danlynes@res.com   !
!  www.res.com/~danlynes/index.html                    !
!  www.res.com/~danlynes/Enitharmon!2/index.html       !
!  The Enitharmon Beta project is now under way.       !
!  To subscribe to the mailing list, send e-mail to    !
!  danlynes@res.com                                    !
+------------------------------------------------------+

In article <danpop.824430285@rscernix>, danpop@mail.cern.ch says...
>
>In <4ftusv$181@newshost.cyberramp.net> sinan@cyberramp.net (John Noland) writes:
>
>>The open() function and its ilk are normally referred to as the "low-level"
>>I/O package. fopen() is the "Buffered" or "Standard" I/O package. The 
>>strength of the low-level I/O functions is that they offer excellent control,
>>particularly when used with binary files.
>
>???  What can read/write do on a binary file that fread/fwrite cannot do?

Where in the above did I compare them with each other? 

>
>>If you have a special I/O need, you
>>can use the low-level I/O routines to fashion the exact I/O package to fit
>>your needs. 
>
>Same question as above.

Same question from me again. Are the read/write functions written using fread/
fwrite or is it vice versa? I believe, and feel free to correct me if I'm 
wrong, that the fread/fwrite functions are written using the read/write 
functions.

>
>>The standard I/O package is one such creation. It is designed to provide fast
>>buffered I/O, mostly for text situations.
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^
>???

I use the stdio routines almost exclusively myself. Even for binary files. 
That doesn't make the above statement wrong. Your statements seem to imply 
that all systems are buffered at the OS level, so who cares what I/O 
approach you use. You're not going to see any difference in I/O speed no 
matter what. While this may be true for your particular situation, it's by 
no means universal. The usefulness of buffering is in working sequentially
with a file. This makes buffered I/O well suited for text files. That 
doesn't mean you can't or won't read a binary file sequentially or that it 
sucks for use with binary files. Which, judging from what you've written,
is exactly what you'll think I meant. 

>>For a lot of applications, using the
>>standard I/O package is simpler and more effective than using simple low-level
>>output. The essential feature is its use of automatic buffering. Buffered 
>>I/O means reading and writing data in large chunks from a file to an array
>>and back. Reading and writing data in large chunks greatly speeds up the I/O
>>operations, while storing in an array allows access to the individual bytes.
>>The advantages of this approach should be apparent.
>
>Except that you can read and write data in large chunks using stdio 
>routines.  The impact of the extra level of buffering is insignificant.

Isn't the above blurb talking about the stdio routines? Once again, your 
reference to an extra level of buffering is not applicable to all systems. 
If you're really referring to the low-level routines, then your statement 
is not always true.

>
>>When fopen() is used, several things happen. The file, of course, is opened.
>>Second, an external character array is created to act as a buffer. The 
>><stdio.h> file has this buffer set to a size of 512 bytes.
>
>To a default size of _minimum_ 256 bytes.  I'm typing this text on a
>system which uses a default buffer size of 8192 bytes.  The size of the
>buffer can be controlled by the programmer via the setvbuf function.
>

That's a big default buffer. How many disk accesses does it take to fill 
that thing? I seriously doubt you would want a buffer that big when reading 
a file randomly. But, maybe your system is so fast you can afford that kind 
of waste. In my <stdio.h> file, the constant BUFSIZ is 512. You say that 
you can control the size of the buffer using setvbuf(). That's true, but it
doesn't change the default buffer size as you seem to imply. If I do the 
following:

FILE *input, *output;

input = fopen("myfile.in", "r+b");
setvbuf(input, NULL, _IOFBF, 1024);

output = fopen("myfile.out", "w+b");

do you think output points to a buffer of the size set by setvbuf?  I don't 
think this is what you meant. 


>>Technically, in DOS, all I/O is buffered since DOS itself uses buffers
>>for disk I/O. 
>
>The same applies to other operating systems (e.g. Unix) except that they
>do a much better job at buffering I/O than MSDOS.

Some versions of UNIX don't do any buffering at all.

>
>>Hope this clarifies things.
>
>So many inaccurate statements don't clarify things.  On the contrary.

The shit you have to up with when trying to be helpful. 

John

In <4g39d4$ej8@newshost.cyberramp.net> sinan@cyberramp.net (John Noland) writes:

>In article <danpop.824430285@rscernix>, danpop@mail.cern.ch says...
>>
>>In <4ftusv$181@newshost.cyberramp.net> sinan@cyberramp.net (John Noland) writes:
>>
>>>The open() function and its ilk are normally referred to as the "low-level"
>>>I/O package. fopen() is the "Buffered" or "Standard" I/O package. The 
>>>strength of the low-level I/O functions is that they offer excellent control,
>>>particularly when used with binary files.
>>
>>???  What can read/write do on a binary file that fread/fwrite cannot do?
>
>Where in the above did I compare them with each other? 

In the above paragraph.  The "low-level I/O functions" means essentially
read/write.
>>
>>>If you have a special I/O need, you
>>>can use the low-level I/O routines to fashion the exact I/O package to fit
>>>your needs. 
>>
>>Same question as above.
>
>Same question from me again. Are the read/write functions written using fread/
>fwrite or is it vice versa? I believe, and feel free to correct me if I'm 
>wrong, that the fread/fwrite functions are written using the read/write 
>functions.

True (in Unix, probably false on other platforms) but irrelevant.  There
are no I/O needs that can be satisfied by one set of functions and not
by another, unless we start talking about Unix-specific features
(pipes, sockets, select()).
>>
>>>The standard I/O package is one such creation. It is designed to provide fast
>>>buffered I/O, mostly for text situations.
>>               ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>???
>
>I use the stdio routines almost exclusively myself. Even for binary files. 
>That doesn't make the above statement wrong. Your statements seem to imply 
>that all systems are buffered at the OS level, so who cares what I/O 
>approach you use. You're not going to see any difference in I/O speed no 
>matter what. While this may be true for your particular situation, it's by 
>no means universal. The usefulness of buffering is in working sequentially
>with a file. This makes buffered I/O well suited for text files. That 
>doesn't mean you can't or won't read a binary file sequentially or that it 
>sucks for use with binary files. Which, judging from what you've written,
>is exactly what you'll think I meant. 

You meant that stdio routines are somehow more suitable for text I/O,
which doesn't happen to be true.  The stdio buffering is a red herring, 
because it can be always disabled, if it isn't needed.

>>>For a lot of applications, using the
>>>standard I/O package is simpler and more effective than using simple low-level
>>>output. The essential feature is its use of automatic buffering. Buffered 
>>>I/O means reading and writing data in large chunks from a file to an array
>>>and back. Reading and writing data in large chunks greatly speeds up the I/O
>>>operations, while storing in an array allows access to the individual bytes.
>>>The advantages of this approach should be apparent.
>>
>>Except that you can read and write data in large chunks using stdio 
>>routines.  The impact of the extra level of buffering is insignificant.
>
>Isn't the above blurb talking about the stdio routines? Once again, your 
>reference to an extra level of buffering is not applicable to all systems. 
???  Do you mean there are systems where stdio doesn't perform its own
buffering?

>If you're really referring to the low-level routines, then your statement 
>is not always true.

I was referring to the stdio routines.  In the (rare) cases where the
stdio buffering has a non-negligible impact, it can be simply disabled.

>>>When fopen() is used, several things happen. The file, of course, is opened.
>>>Second, an external character array is created to act as a buffer. The 
>>><stdio.h> file has this buffer set to a size of 512 bytes.
>>
>>To a default size of _minimum_ 256 bytes.  I'm typing this text on a
>>system which uses a default buffer size of 8192 bytes.  The size of the
>>buffer can be controlled by the programmer via the setvbuf function.
>>
>That's a big default buffer. How many disk accesses does it take to fill 
>that thing?

If its size matches the size of the lower level buffer, the number of
disk accesses is irrelevant, because the same number will be performed
even if I ask read() to read 1 byte from the file.  The implementor is
the one who actually _knows_ what is the optimal size.  And the implementor
decided that the st_blksize field of the stat struct should be set to
(pure coincidence :-) 8192.  For the Unix illiterate:

    ues5:~/tmp 201> grep st_blksize /usr/include/sys/stat.h
	ulong_t st_blksize;  /* Optimal blocksize for file system i/o ops */

>I seriously doubt you would want a buffer that big when reading 
>a file randomly. But, maybe your system is so fast you can afford that kind 
>of waste. In my <stdio.h> file, the constant BUFSIZ is 512. 

Aha, I see where the magical value 512 came from.  The systems I'm working
on have BUFSIZ set to values between 1024 (mostly BSD-based Unices) and 
32768 (OpenVMS).  So, your claim that <stdio.h> sets the size of the
buffer to 512 bytes is bogus.  BTW, even 512 is a humongous size for a
single density 8" floppy disk, which needs to read four sectors to fill
such a buffer.

>You say that 
>you can control the size of the buffer using setvbuf(). That's true, but it
>doesn't change the default buffer size as you seem to imply.

Huh???  Where did I imply that setvbuf changes the _default_ buffer size.

>If I do the following:
>
>FILE *input, *output;
>
>input = fopen("myfile.in", "r+b");
>setvbuf(input, NULL, _IOFBF, 1024);
>
>output = fopen("myfile.out", "w+b");
>
>do you think output points to a buffer of the size set by setvbuf? 

Which should I think such a stupidity?

>I don't think this is what you meant. 

And I _definitely_ didn't mean that.

>>>Technically, in DOS, all I/O is buffered since DOS itself uses buffers
>>>for disk I/O. 
>>
>>The same applies to other operating systems (e.g. Unix) except that they
>>do a much better job at buffering I/O than MSDOS.
>
>Some versions of UNIX don't do any buffering at all.

Care to mention a few examples?  Unix has had block devices for as long
as I can remember.  And I have yet to see a disk which can perform a
1-byte write.  But wait, you can always read a full sector in memory,
change the byte and write back the sector immediately.  Voila, Unix without
buffering.  Performance?  Who cares about performance???

>>>Hope this clarifies things.
>>
>>So many inaccurate statements don't clarify things.  On the contrary.
>
>The shit you have to up with when trying to be helpful. 

And when you don't succeed.  Spreading misinformation doesn't help anybody.

Dan
--
Dan Pop
CERN, CN Division
Email: danpop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

In article <4g39d4$ej8@newshost.cyberramp.net>,
John Noland <sinan@cyberramp.net> wrote:
>In article <danpop.824430285@rscernix>, danpop@mail.cern.ch says...
>>In <4ftusv$181@newshost.cyberramp.net> sinan@cyberramp.net (John Noland) writes:
>>>The open() function and its ilk are normally referred to as the "low-level"
>>>I/O package. fopen() is the "Buffered" or "Standard" I/O package. The 
>>>strength of the low-level I/O functions is that they offer excellent control,
>>>particularly when used with binary files.

>>???  What can read/write do on a binary file that fread/fwrite cannot do?

>Where in the above did I compare them with each other? 

Well, "they offer excellent control, particularly when used with binary
files" would imply that they can do things that the others can't.

>>>If you have a special I/O need, you
>>>can use the low-level I/O routines to fashion the exact I/O package to fit
>>>your needs. 

>>Same question as above.

>Same question from me again. Are the read/write functions written using fread/
>fwrite or is it vice versa? I believe, and feel free to correct me if I'm 
>wrong, that the fread/fwrite functions are written using the read/write 
>functions.

They are sometimes.  Sometimes it's done the other way, and sometimes it's
all done in terms of the native syscalls which may be different.  But, you
failed to answer his question:  In what way can you customize the
low level calls that you can't the high level calls?  There are answers,
but they have *nothing* to do with C.

>>>The standard I/O package is one such creation. It is designed to provide fast
>>>buffered I/O, mostly for text situations.
>>               ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>???

>I use the stdio routines almost exclusively myself. Even for binary files. 
>That doesn't make the above statement wrong. Your statements seem to imply 
>that all systems are buffered at the OS level, so who cares what I/O 
>approach you use. You're not going to see any difference in I/O speed no 
>matter what. While this may be true for your particular situation, it's by 
>no means universal. The usefulness of buffering is in working sequentially
>with a file. This makes buffered I/O well suited for text files. That 
>doesn't mean you can't or won't read a binary file sequentially or that it 
>sucks for use with binary files. Which, judging from what you've written,
>is exactly what you'll think I meant. 

Well, binary files benefit just as dramatically from buffering.  Simple
test programs run on the order of 10 times faster for me using stdio instead
of the low level calls, unless they consciously make an effort to act like
the stdio buffering - in which case, why bother?  stdio does it better than
I do.

>>>When fopen() is used, several things happen. The file, of course, is opened.
>>>Second, an external character array is created to act as a buffer. The 
>>><stdio.h> file has this buffer set to a size of 512 bytes.

>>To a default size of _minimum_ 256 bytes.  I'm typing this text on a
>>system which uses a default buffer size of 8192 bytes.  The size of the
>>buffer can be controlled by the programmer via the setvbuf function.

>That's a big default buffer. How many disk accesses does it take to fill 
>that thing? I seriously doubt you would want a buffer that big when reading 
>a file randomly. But, maybe your system is so fast you can afford that kind 
>of waste. In my <stdio.h> file, the constant BUFSIZ is 512. You say that 
>you can control the size of the buffer using setvbuf(). That's true, but it
>doesn't change the default buffer size as you seem to imply. If I do the 
>following:

>FILE *input, *output;

>input = fopen("myfile.in", "r+b");
>setvbuf(input, NULL, _IOFBF, 1024);

>output = fopen("myfile.out", "w+b");

>do you think output points to a buffer of the size set by setvbuf?  I don't 
>think this is what you meant. 

No, what he probably means is that, on his system, BUFSIZ is 8192.  This
is not atypical.  It probably takes one disk access; it's a common disk
block size on BSD-like unix systems, and probably on many others.  In
which case, it takes about the same time to read a 1k block as to read
an 8k block.

But your system's BUFSIZ has *nothing* to do with the language spec; as Dan
says, 256 or larger is ok.

>>The same applies to other operating systems (e.g. Unix) except that they
>>do a much better job at buffering I/O than MSDOS.

>Some versions of UNIX don't do any buffering at all.

Well, they can be told specifically not to, but I haven't *ever* seen or
used one that doesn't buffer pretty dramatically.  I'm accustomed to
working with projects with a megabyte of source, and doing entire edit/build/
test cycles without disk activity.  That's about a 6 meg buffer.

>>So many inaccurate statements don't clarify things.  On the contrary.

>The shit you have to up with when trying to be helpful. 

Makes sense; if you say a lot of things which are only partially true, or
untrue, you aren't being very helpful, and people are likely to complain.

Not to mention, the whole low level IO thing is really not very much a
part of C.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1995 Peter Seebach.
C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
FUCK the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - ftp taniemarie.solon.com /pub/c/afq - Not A Flying Toy

In article <danpop.824525964@rscernix>, danpop@mail.cern.ch says...

>In the above paragraph.  The "low-level I/O functions" means essentially
>read/write.

That's right. I'm sorry. If that implies a comparison to the stdio routines,
then either you're reading it wrong or I was ambiguous. I'll take the hit
there. This whole thing was written as a response to someone asking a simple
question. The other responses I read were unsatisfactory. "Uh, I think it
has to do with UNIX compatibility", "fopen is buffered, open isn't", "fopen
is ANSI, open isn't". While all of these responses have some validity, they
don't give any feel for what the routines are good for.
I tried to respond in a straightforward manner, aiming primarily at the newer 
C programmer. My point that the low level routines offer excellent control 
to the programmer is a valid one. That this control is especially useful for 
binary files is also valid.
If you were writing a relational database or the input system for a lexical 
analyzer, which routines would you use? It's likely your answer differs from
mine. IMO, the standard C buffered (stdio) routines are a poor choice for 
either of these applications. If memory serves me, UNIX lex is written using 
the stdio routines, and that's fine. It's just not the way I'd do it. 

>True (in Unix, probably false on other platforms) but irrelevant.  There
>are no I/O needs that can be satisfied by one set of functions and not
>by another, unless we start talking about Unix-specific features
>(pipes, sockets, select()).

The original question was something to the effect of, "What is the difference 
between fopen and open and when should I use one over the other?". Are you 
saying I should have answered with, "They are functionally identical. There 
is no difference between them, whatsoever. Always use fopen(), PERIOD!!!".

>The stdio buffering is a red herring, because it can be always disabled, if it 
>isn't needed.

That's true. But if you're going to disable it, why not use the other routines? 
They're smaller. I guess portablity would be a valid reason. The stdio routines 
are ANSI and the others aren't. 

>In my <stdio.h> file, the constant BUFSIZ is 512. 

>Aha, I see where the magical value 512 came from.  The systems I'm working
>on have BUFSIZ set to values between 1024 (mostly BSD-based Unices) and 
>32768 (OpenVMS).  So, your claim that <stdio.h> sets the size of the
>buffer to 512 bytes is bogus.  BTW, even 512 is a humongous size for a
>single density 8" floppy disk, which needs to read four sectors to fill
>such a buffer.

This has an extemely condescending feel to it. Aha? Magical value? 
Your claim that <stdio.h> sets the size of the buffer? The clouds
have parted. I see clearly now. Dan has bestowed upon me the titles
C NEWBIE and UNIX Illiterate. 
BUFSIZ is in <stdio.h>. To say that the size of the buffer is set **IN**
the stdio.h file is not wrong or misleading. Not by any stretch of the
imagination. But you managed anyway. Since this thread is running in
both the c.l.c and msdos.programmer groups, I used the value most DOS 
compilers use. 

>Huh???  Where did I imply that setvbuf changes the _default_ buffer size.
> Snip...
>Care to mention a few examples?  Unix has had block devices for as long
>as I can remember.

Sorry, Dan. Just teasing you a little bit. Trying to get your goat, as it 
were. In retrospect, not a very constructive thing to do during a serious 
debate on the merits of open() vs. fopen(). :)

Again,sorry Dan. It just seemed like you were bragging about UNIX and 
putting down DOS (god forbid). I was hurt and offended (not really).
DOS is inferior to UNIX in almost every respect. Why isn't UNIX the
most dominant OS in the world? 

-John

In <4gbdfr$l2a@newshost.cyberramp.net> sinan@cyberramp.net (John Noland) writes:

>The original question was something to the effect of, "What is the difference 
>between fopen and open and when should I use one over the other?". Are you 
>saying I should have answered with, "They are functionally identical. There 
>is no difference between them, whatsoever. Always use fopen(), PERIOD!!!".

For comp.lang.c, read/write and fread/fwrite _are_ functionally identical
and "Always use fopen(), PERIOD!!!" is the right message that has to be
sent to c.l.c readers.  Those who're really interested in the differences
should be sent to a platform specific newsgroup, because the differences
_are_ platform specific.

>>The stdio buffering is a red herring, because it can be always disabled, if it 
>>isn't needed.
>
>That's true. But if you're going to disable it, why not use the other routines? 
>They're smaller. I guess portablity would be a valid reason. The stdio routines 
>are ANSI and the others aren't. 

The stdio routines provide more functionality: what's the raw I/O 
equivalent of fscanf?  A very good reason to prefer stdio even if you
decide (for whatever reason) to disable the stdio buffering.

>>In my <stdio.h> file, the constant BUFSIZ is 512. 
>
>>Aha, I see where the magical value 512 came from.  The systems I'm working
>>on have BUFSIZ set to values between 1024 (mostly BSD-based Unices) and 
>>32768 (OpenVMS).  So, your claim that <stdio.h> sets the size of the
>>buffer to 512 bytes is bogus.  BTW, even 512 is a humongous size for a
>>single density 8" floppy disk, which needs to read four sectors to fill
>>such a buffer.
>
>This has an extemely condescending feel to it. Aha? Magical value? 
>Your claim that <stdio.h> sets the size of the buffer? The clouds
>have parted. I see clearly now. Dan has bestowed upon me the titles
>C NEWBIE and UNIX Illiterate. 
>BUFSIZ is in <stdio.h>. To say that the size of the buffer is set **IN**
>the stdio.h file is not wrong or misleading. 

Right.  But to say that the value of BUFSIZ is set to 512 in <stdio.h>
is both wrong and misleading.  Saying: "on my system/platform/compiler
BUFSIZ is set to 512 in <stdio.h>" would have been perfectly OK, although
fairly irrelevant, since neither comp.os.msdos.programmer nor 
comp.lang.c are dedicated to your particular compiler.

>Not by any stretch of the
>imagination. But you managed anyway. Since this thread is running in
>both the c.l.c and msdos.programmer groups, I used the value most DOS 
>compilers use. 

And leading other people to believe that it is universal is OK, isn't it?
Especially in the context of c.l.c, where the value used by most DOS
compilers is utterly irrelevant.

>Again,sorry Dan. It just seemed like you were bragging about UNIX and 
>putting down DOS (god forbid).

Could you post the paragraphs (from this particular thread) which gave
you this impression?

>DOS is inferior to UNIX in almost every respect. Why isn't UNIX the
>most dominant OS in the world? 

Are you sure this question belongs to these newsgroups?  Keep your cheap
sarcasms for yourself, please.

Dan
--
Dan Pop
CERN, CN Division
Email: danpop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

sherlock@micronet.fr schrieb:
> natewild@mbnet.mb.ca (Nathan T. Wild) wrote:

> >In C, why would one use open and DOS int handles rather than fopen and
> >stdio file handles?

> >Is there some speed advantage or differnet functionality?


> because files opened using open and DOS files handles can be read and
> write at the same time, while stdio files can't.

That's not correct, I think. You can open files for read/write with the
the stdio routines, too. Just use the "w+", "r+" or "a+" open modes with
fopen().

	fopen( "New.dat", "w+" );

opens a file starting with 0 bytes for writing but with the possibility 
to switch to read mode without the need of closing it.

	fopen( "Old.dat", "r+" );

opens an (existing) file starting with reading with the possibility to
switch to writing without closing.

	fopen( "Any.dat", "a+" );

opens for appending and maybe reading afterwards.

The only thing to assure for read/write switches is to use an
fseek() call between read and write operations:

	fp = fopen( "My.dat", "r+" );
	fwrite( "Hello", 1, 5, fp );
	fseek( fp, 0L, SEEK_SET );
	fread( Message, 1, 5, fp );
	fseek( fp, 0L, SEEK_CUR );
	fwrite( " and Goodby.", 1, 12, fp );
	fclose( fp );


The main difference between stdio calls and the "low-level" routines
(not only under DOS but for Unix too) is the absence of buffering in
the low-level functions.

if you use fwrite(), for example, you can not be sure that the number of 
bytes you want to write are actually written to the output at that time.
The "real" write operation will take place if the stdio buffer for that
file is full.

This can or can not be an advantage for your application. In some cases
you know better when it is the right time to write (or read) and then
the stdio functions contain unneccessary overhead. In other cases the
implemented buffering of stdio input/output will make it unneccessary
to (re)implement an effectiv read/write functionality (I think no one
would like to start the HD motor 1000 times just to write 1000
characters).

But there is another point to keep in mind. The low-level routines
aren't as portable as the stdio functions. Each system has its own
set of functions.

----
Andreas Karnetzki, Munich, Germany.
	Email: medardus@cube.net, CompuServe: 74001,1534

In article <danpop.824829220@rscernix>, danpop@mail.cern.ch says...

>Those who're really interested in the differences should be sent to a 
>platform specific newsgroup, because the differences _are_ platform specific.

I'll buy that. You're right. Truth be told, my original post was made from
the comp.os.msdos.programmer group. I didn't bother to look at the groups
in the header, so that was my mistake. Sorry. I'm just arguing with you
for the sake of arguing. 

> A very good reason to prefer stdio even if you decide (for whatever reason) 
> to disable the stdio buffering.

Another good point, Dan.

>Right.  But to say that the value of BUFSIZ is set to 512 in <stdio.h>
>is both wrong and misleading.  Saying: "on my system/platform/compiler
>BUFSIZ is set to 512 in <stdio.h>" would have been perfectly OK, although
>fairly irrelevant, since neither comp.os.msdos.programmer nor 
>comp.lang.c are dedicated to your particular compiler.

It isn't nearly as much fun agreeing with you, Dan. But, you're right
again.

>Could you post the paragraphs (from this particular thread) which gave
>you this impression?

The same applies to other operating systems (e.g. Unix) except that they
do a much better job at buffering I/O than MSDOS.

>Are you sure this question belongs to these newsgroups?  Keep your cheap
>sarcasms for yourself, please.

I don't know if it belongs *to* these newsgroups or not. It probably 
doesn't belong in *this* newsgroup. As a matter of fact, your posting
of the old April Fool's joke about the C/UNIX hoax seems a wee bit off
topic itself. Mind you, it doesn't bother me in the least, but I would 
think you'd know better.

You're one serious man, Dan. I've read a lot of your posts, so I know
you have at least a slight sense of humor. Lighten up. By the way, is 
your middle name, by chance, Persnickety? Dan Persnickety Pop! That has 
a nice ring to it.

-John

In article <danpop.824829220@rscernix>, Dan Pop <danpop@mail.cern.ch> wrote:
 >>Again,sorry Dan. It just seemed like you were bragging about UNIX and 
 >>putting down DOS (god forbid).
 >
 >Could you post the paragraphs (from this particular thread) which gave
 >you this impression?

If Dan were advocating UNIX over DOS, would he not suggest that people avoid
stdio functions and go right for the cool UNIX/POSIX system calls?

After all, the lame standard library, despite giving you fscanf(), has no
equivalents for select(), fork() or mmap(). Everyone knows that memory mapped
files are far cooler that sucking bytes through a straw known as stdio.

But Dan, being the gentleman, suggests that in a newsgroup that embraces all
standard implementations of C regardless of platform, the proper recommendation
should be that C programs use the standard library, wherever it applies.

 >>DOS is inferior to UNIX in almost every respect. Why isn't UNIX the
 >>most dominant OS in the world? 
 >
 >Are you sure this question belongs to these newsgroups?  Keep your cheap
 >sarcasms for yourself, please.

It is _not_ the most dominant? Out of things that are entitled to be called
"OS", it sure is.
-- 

In <4gg5nk$he1@salyko.cube.net> medardus@cube.net (Andreas Karnetzki) writes:

>The main difference between stdio calls and the "low-level" routines
>(not only under DOS but for Unix too) is the absence of buffering in
>the low-level functions.

Are you sure?  Unix does a lot of "raw" I/O buffering (hence the sync()
and fsync() system calls) and I'm just wondering what could be the use
of the BUFFERS parameter of MSDOS (I have a feeling that it isn't
related to the C stdio library)?  How about a certain SMARTDRV.EXE or
the various disk "doublers"?

Dan
--
Dan Pop
CERN, CN Division
Email: danpop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

In article <4gg5nk$he1@salyko.cube.net>
           medardus@cube.net "Andreas Karnetzki" writes:

>sherlock@micronet.fr schrieb:
>> natewild@mbnet.mb.ca (Nathan T. Wild) wrote:
>
>> >In C, why would one use open and DOS int handles rather than fopen and
>> >stdio file handles?
>
>> >Is there some speed advantage or differnet functionality?
>
>
>> because files opened using open and DOS files handles can be read and
>> write at the same time, while stdio files can't.
>
>That's not correct, I think. You can open files for read/write with the
>the stdio routines, too. Just use the "w+", "r+" or "a+" open modes with
>fopen().
>
>        fopen( "New.dat", "w+" );
>
>opens a file starting with 0 bytes for writing but with the possibility 
>to switch to read mode without the need of closing it.
>
>        fopen( "Old.dat", "r+" );
>
>opens an (existing) file starting with reading with the possibility to
>switch to writing without closing.
>
>        fopen( "Any.dat", "a+" );
>
>opens for appending and maybe reading afterwards.
>
>The only thing to assure for read/write switches is to use an
>fseek() call between read and write operations:
>
>        fp = fopen( "My.dat", "r+" );
>        fwrite( "Hello", 1, 5, fp );
>        fseek( fp, 0L, SEEK_SET );

You could have fflush(), rewind() or fsetpos() instead here.

>        fread( Message, 1, 5, fp );
>        fseek( fp, 0L, SEEK_CUR );

You could have rewind() or fsetpos() instead here.

>        fwrite( " and Goodby.", 1, 12, fp );
>        fclose( fp );

>The main difference between stdio calls and the "low-level" routines
>(not only under DOS but for Unix too) is the absence of buffering in
>the low-level functions.

The 'low-level' functions typically have buffering in the OS. However
stdio typically implements an extra level of buffering local to the
particular program.

>if you use fwrite(), for example, you can not be sure that the number of 
>bytes you want to write are actually written to the output at that time.
>The "real" write operation will take place if the stdio buffer for that
>file is full.

A good implementation of fwrite could bypass the stdio buffering where the
block sizes were appropriate.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------