[comp.lang.c] Low Level I/O and ANSI C

burton@nicmad.UUCP (Kevin Burton) (12/01/89)

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) ?

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

================================================================================
          att!terminus-----\		           |
     harvard-\         att--\                      | Kevin Burton (608) 276-6166
        ucbvax!uwvax!astroatc!nicmad!burton        | Nicolet Instrument Corp.
    rutgers--/       rolls--/                      | 5225-2 Verona Rd
      ames--/       decvax-/                       | Madison, WI 53711-0288 
================================================================================

henry@utzoo.uucp (Henry Spencer) (12/02/89)

In article <3909@nicmad.UUCP> burton@nicmad.UUCP (Kevin Burton) writes:
>..."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>".
>
>... What are the reasons for removing the low level
>I/O from the standard libraries? ...

They have never been part of the standard C libraries; they have always been
part of the standard *Unix* libraries.  They are not in C libraries because
they are not portable.  On many systems it is impossible to implement
anything that behaves like Unix read(), for example.  If you want to write
portable code, you have to use portable primitives.

>... For a system that
>supports ANSI C will there be none of these type of routines (low-level) ?

It is entirely possible that they will exist; in a Unix system or a POSIX-
compliant system, they will.  In many other ANSI C implementations, they
won't.  It's simply a question of how portable you want your code to be.
There is great pressure on OS suppliers to be POSIX-compliant, so a wide
variety of systems will probably provide Unix-like low-level calls.  There
will still be many systems that won't or can't.  For maximal portability,
write in ANSI C and don't use system-dependent low-level library routines.

>...In the past we ALWAYS took a performance
>hit when using the higher level stream I/O routines....

Complain to your vendors.  Traditional implementations of the C stream I/O
functions *are* slow, but there is much that can be done to speed them up
if the implementor *tries*.
-- 
Mars can wait:  we've barely   |     Henry Spencer at U of Toronto Zoology
started exploring the Moon.    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

gwyn@smoke.BRL.MIL (Doug Gwyn) (12/02/89)

In article <3909@nicmad.UUCP> burton@nicmad.UUCP (Kevin Burton) writes:
>What are the reasons for removing the low level I/O from the standard
>libraries?

They weren't "removed"; they were never part of the standard I/O library
in the first place and were insufficiently portable to include in the C
Standard.  Many existing C implementations do not include such functions.
Those that do generally modelled them after the UNIX system calls,
although since UNIX doesn't maintain file organization types and most
other operating systems do the emulation was often rather imperfect.

IEEE Std 1003.1 does specify such functions for POSIX implementations.

>In the past we ALWAYS took a performance hit when using the higher
>level stream I/O routines.

I've seen performance gains when the buffering stdio functions were
used instead of a succession of smaller-transfer system calls on UNIX
systems.  It all depends on what you're doing and on how well stdio
is implementated and how well it fits the application's needs.

>For a system that supports ANSI C will there be none of these type of
>routines (low-level) ?

Strictly conforming (i.e. maximally portable) programs cannot rely on
their existence; this is already true and nothing has changed in this
respect with the advent of the C Standard.  It is highly probable that
compiler vendors who formerly supplied open() etc. functions in their
C libraries will continue to do so in their Standard-conforming
implementations as well; that is not prohibited by the C Standard.

You need to understand that the C Standard is not intended to prevent
vendor-specific extensions, although it does insist that such
extensions not interfere with the operation of portable programs.
Standard C is intended to form a universal subset that can be relied
upon to be implemented everywhere, and necessarily this cannot include
features that don't make sense everywhere or for which a portable
specification would be so weak as to be of little value.  Applications
need not be written to use only the features guaranteed by the C
Standard, but if they require more support than that then they may not
port easily to environments that fail to provide the extra support.

dricejb@drilex.UUCP (Craig Jackson drilex1) (12/03/89)

In article <3909@nicmad.UUCP> burton@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@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}