🚀 go-pugleaf

In article <4c9i65$3b6@segfault.monkeys.com>,
Ronald F. Guilmette <rfg@monkeys.com> wrote:
>I have a question about the traditional implementation of buffered FILEs.
>
>(My apologies to readers of comp.std.c.  I know this isn't a question
>which relates directly to the text of the C standard, but I do need to
>put the question to people who are well versed in the details of C imple-
>mentations, and comp.std.c is one likely place to find such people.)
>
>Traditional implementations of getc and putc look pretty much as follows:
>
>----------------------------------------------------------------------------
>#define getc(p)         (--(p)->_cnt < 0 ? __filbuf(p) : (int)*(p)->_ptr++)
>#define putc(x, p)      (--(p)->_cnt < 0 ? __flsbuf((unsigned char) (x), (p)) \
>                                : (int)(*(p)->_ptr++ = (x)))
>----------------------------------------------------------------------------
>
>The important point to note here is each of these macros causes the
>``file pointer'' (_ptr) to be incremented... in a very simple-minded
>fashion... whenever a character is taken from, or added to the FILE's
>buffer (respectively).
>
>From this fact I deduce that traditional implementations of the entire
>stdio set of functions _do not_ treat FILE buffers as so-called ``circular
>buffers'' but rather treat them a mere linear buffers.
>
>My question is just this... Why?
>
>Given that traditional implementations of the FILE structure include a
>``_cnt'' field, it seems to me that it would have been possible... albeit
>at a slight cost... to treat FILE buffers as circular buffers, wraping
>the value of _ptr back to the physical beginning of the buffer each time
>it was seen to have passed the physical end of the buffer.  But it seems
>that nobody does this.  Why not?

Why bother?

The purpose of a buffered file is to improve performance by reducing the number
of physical I/O operations.

Lets look at the 2 major cases, input and output.

If the buffered file is used for input. You first fill the buffer.  Then as
long as the buffer isn't empty, you return bytes from the buffer.  When the
buffer finally empties, you fill it again.  Notice that you never perform a
physical I/O on the buffer unless it is empty.  Implimenting the buffer as
a circular buffer wouldn't improve performance and would just make it more
complex.

Now if the file is being used for output.  You start with an empty buffer.  You
proceed to fill the buffer.  When ever the buffer fills, you flush it to the
physical device. Once again, the only physical operation is to flush the entire
contents of the buffer.  When you write anything from the buffer, you write the
entire contents of the buffer.  So a circular buffer wouldn't gain you anything
except more complexity.

Hope this helps.