🚀 go-pugleaf

In article <1hnqdeINN15a@duca.hi.com> wright@duca.hi.com (David Wright) writes:
>In addition, fseek() is generally moronic about checking whether the
>new file pointer is within the current buffer.  That is to say, it
>doesn't check.  So if you, say, try to read a file backwards, one byte
>at a time, you'll do as many reads as there are bytes in the file.

Speak for yourself. :-)

I wrote most of the 4.4BSD stdio (bugs and all---so far we have found
and fixed three or four).  My fseek() can read a file backwards fairly
quickly.  You will do better if you read() directly---no general
subroutine can be perfectly optimal for all tasks---but there is no
longer an order of magnitude slowdown for short backwards seeks when
reading.

(Note that, when writing, fseek must perform an fflush(), which translates
into a write and thus may involve block allocation and other very slow
tasks.  The code for reading is largely separate.)

None of this has anything to do with UNIX: fseek()'s operation is
defined by ANSI standard X3.159-1989 and its various equivalents.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov