🚀 go-pugleaf

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