Low Level I/O and ANSI C (open,close,read,write,lseek)

[Craig Jackson drilex1]

In article <3909 at nicmad.UUCP> burton at nicmad.UUCP (Kevin Burton) writes:
>I was reading the book _Standard C_ by P.L. Plauger & Jim Brodie and came
>across the statement, "Many earlier implementations offer an additional
>set of input/output functions with names such as close, creat, lseek, open,
>read, and write. You must replace calls to these functions with calls to
>other functions defined in <stdio.h>".
>
>I am new to USENET and am fairly new to ANSI C (though I have been 
>programming in K&R C for quite some time) so please be patient if it seems
>that I am just waking up. What are the reasons for removing the low level
>I/O from the standard libraries? In the past we ALWAYS took a performance
>hit when using the higher level stream I/O routines. For a system that
>supports ANSI C will there be none of these type of routines (low-level) ?

That lower level may not exist.  ANSI C is useful in many environments
which are not Unix.  Few other environments implement an undifferentiated
byte stream model for files, and few other environments implement text files
as variable-length-records-terminated-by-linefeeds, as Unix does.  Also,
few older systems implement any form of 'file descriptor', at least not
using small integers.

open/read/write/close tend either to be hard to implement, or to be not
very useful, in those environments.  If open/read/write/close is mapped
in the simplest manner onto a file system which has record structure and
whose interface includes user-declared control blocks, the warts of the
records become highly apparent and the user is limited to a few files open.

If the implementation tries a little harder, one can create an open/read/write/
close implementation which offers more Unix semantics, but is incompatible
with the host system and runs like a pig, to boot.  For example, at least
one version of Lattice C for the 370 implements open/read/write/close using
files with a logical-record-length of 1.  This closely mirrors the semantics
of Unix, but many other programs on the 370 wouldn't understand such a file.
Also, file system routines which are designed to deal with 80 or more
bytes at a time probably aren't too efficient when called one byte at a time.

By standardizing on stdio, the ANSI C committee created a file system
interface which is usefully implementable on many more systems than Unix.
By adding the distinction between binary and text file access, the 
committee also made it possible for C programs to access non-text files
on such systems.  (Note that most programs manipulating binary files on
such systems, except files that are solely meant to interchange with
other C programs, will probably be non-portable.)

>I would appreciate any enlightenment that the USENET community could provide
>on this subject. Thank you in advance.

Hope this helps.

>        ucbvax!uwvax!astroatc!nicmad!burton        | Nicolet Instrument Corp.

Are such elaborate signatures still necessary in this day and age?  (Note that
I cut out the elaboration.)
-- 
Craig Jackson
dricejb at drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}