Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Low Level I/O and ANSI C (open,close,read,write,lseek)
Keywords: ANSI C
Message-ID: <11728@smoke.BRL.MIL>
Date: 2 Dec 89 01:35:47 GMT
References: <3909@nicmad.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 41

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.