cy@dbase.UUCP (Cy Shuster) (09/13/89)
In the recently received Tech Note 246, "Mixing HFS and C File I/O" (thanks to Roger L. Long at the Wolfskill & Dowling residence and comp.binaries.mac), it says not to mix C calls like fopen() with HFS calls. However, is it permissible to mix low level C calls like open() with HFS calls? The MPW 3.0 C manual says it's acceptable as long as you don't close or modify the file pointer by using the reference number. And in fact the FIOREFNUM command to ioctl gives the Mac's vrefnum for the file (see page 126). --Cy--
earleh@eleazar.dartmouth.edu (Earle R. Horton) (09/13/89)
In article <225@dbase.UUCP> cy@dbase.UUCP (Cy Shuster) writes: >In the recently received Tech Note 246, "Mixing HFS and C File I/O" >(thanks to Roger L. Long at the Wolfskill & Dowling residence and >comp.binaries.mac), it says not to mix C calls like fopen() with HFS >calls. However, is it permissible to mix low level C calls like open() >with HFS calls? The MPW 3.0 C manual says it's acceptable as long as you >don't close or modify the file pointer by using the reference number. And >in fact the FIOREFNUM command to ioctl gives the Mac's vrefnum for the >file (see page 126). a) Real Mac programmers don't use STDIO. b) This is a general question, I think, because many systems exist where STDIO is just a sugar coating over calls to a native file system. VMS and iRMX[2]86 are other examples. Usually, you have a choice in such systems: You can use the native system for performance or you can use the sugar-coated STDIO for portability. A third choice is to mix calls for reduced performance, reduced portability, and reduced readability. I strongly advise against mixing HFS and C I/O, except in a high-level manner as shown in the Technote, because in my opinion this practice only serves to add to the complexity of your code without materially simplifying the problem at hand. The question of whether or not it will work is far less important than is the issue of the horrible things this practice does to the maintainability of your code. Earle R. Horton