Path: utzoo!attcan!uunet!cs.utexas.edu!usc!julius.cs.uiuc.edu!psuvax1!psuvm!brl102
From: BRL102@psuvm.psu.edu (Ben Liblit)
Newsgroups: comp.sys.apple2
Subject: Re: HyperC filing question
Message-ID: <90313.144206BRL102@psuvm.psu.edu>
Date: 9 Nov 90 19:42:06 GMT
References: <1990Nov8.045226.7696@wpi.WPI.EDU>
 <90312.134032BRL102@psuvm.psu.edu>
Organization: Penn State University
Lines: 72

A few clarifications to my recent posting concerning binary files in HyperC:

FILE open( TEXT *fname );
-------------------------

   The open() function returns a FILE, not a pointer to a FILE.  Since, in
   HyperC, FILE is simply an int, you can really mess things up if you're
   careless about your pointers.  HyperC couldn't care less if you assign an
   int to a pointer or vice versa.  It's up to the programmer to watch out for
   this.

   Yes, open() does *not* take a second parameter.  ProDOS, and therefore
   HyperC, could not care less wether you are opening to read or write, or text
   versus binary.  It's up to you, the programmer, to deal with files in the
   proper manner.


FILE create( TEXT *fname );
---------------------------

   open() will *not* create a new file.  To start a new file, you should use
   create() instead.  create() actually performs three calls to the operating
   system, through MLI: destroy, create, and open.  Call it as you would call
   open(), and remember that it takes care of opening the file for you (i.e.,
   don't follow up create() with a call to open()).


INT getc( FILE fd );
--------------------

   This returns a single character from the given file.  Again, watch those
   pointers!  The return value is an int, not a char, so that -1 can be
   returned on errors.


VOID putc( FILE fd );
---------------------

   The counterpart to getc(), this function writes a single byte to the given
   file.  It does *not* have a specified return value.


Error Codes
-----------

   Create(), open(), and getc() return -1 to indicate an error condition.
   Additionally, the actual ProDOS error code is placed in _ioresult.  Declare
   "extern int _ioresult;" if you wish to access it.  The linker will resolve
   the reference.

   On the other hand, read(), write(), and putc() will *not* return -1 to
   signal an error.  Read() and write() return simply the actual number of
   bytes read or written.  Putc()'s return value is *unspecified*.  If an error
   occurs, all three of these function *will* set _ioresult to the ProDOS error
   code.

   For most applications the use read() and write(), it should not be necessary
   to check _ioresult after each call.  Instead, simply compare the *requested*
   number of bytes with the *actual* number of bytes.  If they're different,
   something went wrong.  This works especially well for checking for EOF after
   a read() call.  If EOF was reached, read() will return fewer bytes than were
   requested.

One final note -- don't use read() and write() for characters.  Yeah, they'll
work, if you get the parameter types cast just right, but it's not worth it.
Use putc() and getc() instead ... they're quicker, require less code, and much
easier to use.  And whatever you do, don't call printf( fd, "%c", letter ) !!!
Can you say "unnecessary overhead"?  I new you could.

                            Ben Liblit
                            BRL102 @ psuvm.bitnet -- BRL102 @ psuvm.psu.edu
                            "Fais que tes reves soient plus longs que la nuit."