Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!keith
From: keith@Apple.COM (Keith Rollin)
Newsgroups: comp.sys.mac.programmer
Subject: Re: stdio, THINK C and APPLs
Message-ID: <47623@apple.Apple.COM>
Date: 29 Dec 90 01:10:14 GMT
References: <1990Dec27.183436.3786@ux1.cso.uiuc.edu> <47608@apple.Apple.COM> <1990Dec28.162334.20490@ux1.cso.uiuc.edu>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 51

In article <1990Dec28.162334.20490@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes:
>In article <47608@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes:
>>Because the resource fork should be read ONLY with the the Resource
>>Manager.
>
>Horse puppies, again.
>
>Apple provides OpenRF, and allows the reference number thus returned to
>be used in any of the file manager functions (read, write, etc).
>
>I see NO reason why this behavior shouldn't be exactly mirrored in the
>C library.  If it was good enough to put in ROM, it's good enough to
>add the half-dozen lines of code to open and fopen to make it available to
>them as well.  We're not talking about a large investment in time or
>code size.
>
>Arbitrary restrictions are almost always a bad idea.

But automatic mirroring of all ROM routines in the C Libraries isn't
necessarily a good idea either. For instance, if you make a printf()
call, it eventually calls DrawString. This doesn't mean that we should
add an option to printf() that causes the libraries to call TextBox
instead.

And even if a routine is in ROM or implemented by the System and is
documented in Inside Mac or a Technote, that doesn't mean that it
should be called. For example, take InitGDevice or CheckUpdate. These
are routines made available for completeness but it doesn't mean that
you should try to find some place in your program to put them. They are
there in case you really, really, really need them.

Similarly with the OpenRF call. It's there if you really, really,
really need it. However, that doesn't mean that you should call it on a
whim, which some people might do if we made it easy to get at from
fopen(). As was previously posted, use of OpenRF should be limited to
applications that a) need to deal with corrupted resource forks, or
b) need to copy a file. In either of these cases, you are writing
non-portable code, and could just as easily use OpenRF rather than
fopen(). 

As a matter of fact, using the File Manager for file I/O is MUCH better
than using the C Libraries. Those libraries have a lot of generic AT&T
junk in them, and include a LOT of overhead.  For better performance,
use the Mac File Manager routines.

-- 
------------------------------------------------------------------------------
Keith Rollin  ---  Apple Computer, Inc.  ---  Developer Technical Support
INTERNET: keith@apple.com
    UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith
"Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions