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

[Henry Spencer]

In article <3909 at nicmad.UUCP> burton at 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 at zoo.toronto.edu