The "C" library © 1986, By Tim Holloway PRELIMINARY TEST VERSION 0.0, as of July 7, 1986 This package is in the public domain. The only rights reserved are that it may not be sold. It may, however be included in commercial software, as long it is passed on with the selfsame restrictions. Credit to the author is appreciated, but not required. Contributions are appreciated, but don't worry about it. No warranties expressed or implied. DEDICATION: In Memoriam, Janet Holloway - my REAL Amiga. PURPOSE: It seems that use of high-level languages carries an (often stiff) memory penalty. On the other hand, use of assembly language carries an (almost inevitably stiff) programmer penalty. What is needed is some sort of happy medium. In all fairness, if assembly language programs had the extensive formatted I/O capabilities taken for granted by HLL programmers, they'd have memory penalties, too. I've seen far too many assembler programs that have hexadecimal diarrhea and then fall over dead because it was too much trouble for the programmer to format a meaningful message instead of plucking the data out of a core dump. So, while I'm at it, why not some high-level output routines for assembler programs as well? AmigaDOS is highly extensible. It is possible to add features in such a way that it is virtually impossible to determine whether they were supplied by Commodore-Amiga or by some ingenious programmer (i.e. me). A case in point is the AmigaDOS library subsystem. A library, once created, resides in the system LIB: directory (ignoring dynamically-built and ROM libraries). Any program can then do an OpenLibrary and proceed to use the builtin-functions until the program closes the library. If multitasking programs use the library, a single copy of the library is used, loaded automatically when the first task opens it, and remaining resident until all tasks have closed it, resulting in core memory savings. Even more important from my point of view, only one copy of the library routines exists on disk - the program size is reduced to that of the 'glue' routines which are typically much smaller than the actual library routines themselves. This is especially nice when you have a large inventory of small programs. Of course, for one use of one library, there is actually a core and disk PENALTY, but libraries are not intended to be used in this way - there is no purpose in creating a library and its associated glue routines for a single instance. Examining the linkmap of a typical Lattice C program, I discover that the overwhelming bulk of the overhead (i.e. code not written by me) falls into one of three categories, to wit: 1), memory management routines; 2), I/O routines; and 3), formatted I/O routines. Thus, there are three possible areas to attack. Of the three, formatted I/O is the biggest, and is the least likely to be impacted by the performance penalties (admittedly minor, the AmigaDOS library interface is inherently efficient). As time progresses, I reserve the right to add some or all of the other two functions to the library if performance and memory statistics warrant it. I learned a long time ago that trying to deduce inefficiencies is just a wast of time. These days I MEASURE the suckers, because the places that LOOK inefficient often aren't where the real inefficiencies occur. While I'm at it, I intend to swat a few mosquitos in the Lattice I/O system. However, this library is intended to work with Manx Aztec C as well - a different glue module is required for 16-bit integers, that's all (I HOPE! Floating point differences may prove the undoing of this scheme). The standard of behavior to be observed will be that of Unix, as I understand it. I figure to gain the following advantages: 1. Smaller programs, hence more per disketter, and faster load times.. 2. Conserve memory when running C programs in a multitasking environment. 3. Not having to re-link programs if I find that I can optimize the I/O routines. 4. MY version of %g format WORKS! Version 0.0 - preliminary test version. The following restrictions apply: o. printf is limited to 128 characters max of output in a single printf call. o. scanf is not included - the compiler vendor's scanf will be linked in. o. The 'star' convention for field widths does not appear to work. Investigating. o. Floating-point I/O is not supported yet. (Conflicts between Lattice and Manx). Since the Amiga-supplied FP libraries have conversion aids, this might not be as much trouble as I had thought, but that's an issue for a later version of this library. o. I don't know what the Manx setup code looks like. The glue routine is supplied anyway, for anyone who would like to try it. o. If someone attempts to use a C library-based program but does not have c.library in DEVS: an Alert is issued (Unable to open library). This is supposed to be a recovery alert, but at the moment the system crashes after the Alert is acknowledged. Will probably switch to an AutoRequest in a future incarnation. INSTALLATION: The C library comes as as ARC'ed file containing: CLIB.DOC - you're reading it. LCLIB.LIB - clib.lib for Lattice C MCLIB.LIB - clib.lib for Manx C (Note - due to possible floating- point format conflicts, I may not be able to support Manx without more effort). Not present for version 0.0 CL.OBJ - object version of same _MAIN.C - A customized version of _main.c for Lattice. C.LIB - the library itself. To install, 1. Copy C.LIB to "DEVS:C.LIBRARY". 2. Copy LCLIB.LIB or MCLIB.LIB to whatever directory you keep your C support libraries in (typically directory LIBS on the development disk). Name it CLIB.LIB. 3. Ditto for LC.O. Alink for Lattice C should have the following properties: Alink :libs/lc.o+your stuff LIBRARY :libs/clib.lib+:lib/lc.lib+:libs/amiga.lib etc. Now try it on the "Hello, World!" program. To return to 'Normal', just undo the Alink changes, and the vendor- supplied I/O routines will work as before. If you prefer, you may replace Lattice's C.O with the supplied version (the only difference is a call in XCEXIT to _CCleanup in _main.c and the NoClibrary routine, which issues an Alert). In this case, use the supplied _main.c with the CLIBRARY #define de-activated when you don't want to use the C library. Normally I like to publish the source code, just as I like to GET source code. It's not that I'm ASHAMED of the source here (well, er, umm...) - I just want to promote a standard. The only way that I can guarantee that if I uploaded a program that used the C library and you downloaded it that it would run is if there aren't a dozen different variants floating around with conflicting improvements. BUGS: Avoid the '*' width modifiers - they are still running wild. LIMITATIONS: Use only for programs that do not (s/f)printf floating-point numbers. SUPPORT: This is only round 1. I am interested in feedback from users - my network addresses are listed below. Normally the most up-to-date version can be found on the Casa Mi Amiga BBS, followed by Compuserve AMIGAFORUM DL 7. Casa Mi Amiga (904) 733-4515 (Fido Net 112/Node 1) Compuserve [73026,2026] Bix: tholloway