Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pilchuck!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: questions about a backup program for the MS-DOS environment
Message-ID: <2487@dataio.Data-IO.COM>
Date: 4 May 90 19:18:30 GMT
References: <255@uecok.UUCP> <1990Apr25.125806.20450@druid.uucp> <12459@wpi.wpi.edu> <2484@dataio.Data-IO.COM> <CLINE.90May3130316@cheetah.ece.clarkson.edu>
Reply-To: bright@Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 19

In article <CLINE.90May3130316@cheetah.ece.clarkson.edu> cline@sun.soe.clarkson.edu (Marshall Cline) writes:
<Note that Walter used read()/write() as opposed to fread()/fwrite().
<In Turbo-C, it's even faster (probably 2 to 3 times faster!) to use
<_read() and _write(), since read()/write() can end up
<deleting/inserting ^J if the files are in text mode.
<I found fread()/fwrite() in Turbo-C to be embarassingly & surprisingly
<slow.  After tracing them, I found they resolved to loops of
<fgetc()/fputc() rather than the seemingly more obvious read()/write(),
<apparently since fgetc()/fputc() know about buffering.  However it
<wouldn't be hard to fix fread()/fwrite() to do it `right'!

But I wasn't using Turbo C, I was using Zortech C! In Zortech C, read()/
write() resolve directly to calls to MSDOS. read()/write() do not do
CR-LF translation. I always felt it was silly to have them do such
translation, thus creating 3 levels of I/O instead of 2. If you want
CR-LF translation, use fgetc/fputc.

BTW, fread/fwrite directly memcpy the bytes from/to the I/O buffer, they
are not loops around fgetc/fputc for the Zortech libraries.