Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!ames!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.atari.st
Subject: Re: FILE I/O
Message-ID: <8711102023.AA08123@cory.Berkeley.EDU>
Date: Tue, 10-Nov-87 15:23:59 EST
Article-I.D.: cory.8711102023.AA08123
Posted: Tue Nov 10 15:23:59 1987
Date-Received: Fri, 13-Nov-87 00:09:58 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 27

> The raw GEMDOS functions are faster (due to
> no buffering) but you should set up your own buffering.  

	Amusing.  If the raw GEMDOS functions are faster due to not
buffering, why would you want to add buffering?  

	In fact, the raw GEMDOS functions are only faster if you do huge
read/write requests, and even then the difference shouldn't be noticeable.
Try reading a character at a time.... or a line at a time... this is why
buffering exists.

>I don't quite understand this.  If I have to do my own buffering with
>Fread, while fread does the buffering for me, then the fread call
>appears easier to use.  And since the application has to buffer Fread
>calls itself, any speed advantage of Fread (due to no buffering!) is
>negated. So I can see no advantage to the Fread.

	fread() USES Fread().  Using fread() means that more code is imported
from the C link library (or whatever languge you are using).  Fread() is a 
direct OS call.  So if you are an application written in straight assembly,
fread() isn't available to you without setting up the proper enviroment... 
done automatically by the startup code in, say, a C link library.  fread()
would be a function IN that library.  Or, perhaps, you want to save space
and make the executable as small as possible; in that case, you wouldn't 
want to include the X Kbytes of code that stdio takes.

					-Matt