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}