Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!boulder!sunybcs!bingvaxu!leah!itsgw!batcomputer!braner
From: braner@batcomputer.tn.cornell.edu (braner)
Newsgroups: comp.sys.atari.st
Subject: Re: FILE I/O
Message-ID: <2892@batcomputer.tn.cornell.edu>
Date: Tue, 10-Nov-87 14:04:10 EST
Article-I.D.: batcompu.2892
Posted: Tue Nov 10 14:04:10 1987
Date-Received: Thu, 12-Nov-87 23:16:30 EST
References: <2023@homxc.UUCP> <2862@batcomputer.tn.cornell.edu> <2064@homxc.UUCP>
Reply-To: braner@tcgould.tn.cornell.edu (braner)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 14
Keywords: C, Fseek, fseek
Summary: it's fgetc(), etc that are slow

[oops...]

What I meant was that reading a big block is a lot faster than reading
char by char using fgetc() and such (getc, getchar).  If you are going
to read a big block you might as well use low level calls (Fread) for
maximum speed.  But I guess you _could_ use fread() as supplied by your
compiler vendor.  Just hope they implemented it efficiently...

One more warning: if you use a compiler with 16-bit int's (as it should be
on a 68000!) you are limited as to the amounts you can specify in the
count arguments for fread(), malloc(), etc.  You _have_ to descend to
the raw OS calls if you need to use a long count.

- Moshe Braner