The BuRP C Library ================== This is the BUrr-Rushing-Pigg Project C library for AmigaDOS. It provides (most of) the standard functions as specified by the ANSI C Standard and a few more that are intended to emulate Unix system calls. The BuRP C Library is a direct descendant of The PDC C Library release 3.3 from Lionel Hummel. I have added some code from BSD (Univ. of California at Berkeley's "unix") version 4.3/pre-4.4. The rest of the code, and modifications to the PDC and BSD code, can be blamed on me (Ray Burr). The original purpose of this library was to provide a free C library for use with GCC (The Free Software Foundation's GNU Project C compiler) on the Amiga that was at least good enough to compile GCC. It could easily be used with other compilers. Most of the C source code should work with any ANSI compliant C compiler although there may be a few places where GNU C extensions are used. The assembly code is in the old Motorola syntax as expected by A68k. About This Release ================== This is very likely the last release of the BuRP C Library because as of this release it is perfect. There are no more bugs and every possible useful feature has been incorporated into the library... OK, so I'm lying... The truth is that there is another library out there that seems to have most of the features of this one and then some that I either had not thought to be worth my effort or just hadn't gotten around to it. What I have seen of the first release of Marcus Wilds C library looks like a very good start. It is more based on BSD code which I would think might make it more reliable (BSD code itself is better tested) and more compatible with the POSIX standard. A good part of it is pure (no static data) so that it can be put in a shared library. Good work Marcus! My intent is to donate the latest source for the BuRP library as kind-of spare parts for anyone who wants to use it. Use it as a reference or "steal" code from it. The goal of this library was more towards the ANSI C standard before BSD compatibilty (I would expect BSD 4.4 to comply with ANSI or close anyway) so it might (or might not) be of some help in that way. I am still interested in hearing about bugs or fixes, so send me email. Copyrights ========== I have tried to keep the file copyright headers intact for the BSD and PDC code. Any code that I have written will not have a notice in the file, so just see the notice below. Some of the files have been reformated to my (GNUish) style to make it easier for me to work on. Some have been reformated for no good reason (so I got carried away...). Most files in which I have made major modifications say something about being modified. Some of the minor mods might not be documented at all. Files in this library that were written by me, Ray Burr (ryb) go under this copyright (C) 1992: /*********************** Notice of Copyright **************************\ You may modify and/or redistribute the code all you want. Just don't restrict anyone elses right to do so. This notice must be redistributed along with any of the files that it covers. I am not responsible in any way for damages of any kind caused by the code. There is no warranty of any kind for this code. Anyone may substitute any version of the GNU Public License for this notice. \***********************************************************************/ In other words, I'm just not too worried about it. However, if you do want to use this library, or a significant part of it, as the basis for another C library, I would be interested in hearing about it. Bugs / Problems =============== I have been using this library for a while and it seems to be reliable in general but there are a few known problems and (I'm sure) a few unknown bugs. Below is a list of some of the know probems. I am still working on the list of unknown bugs... Math Library: o Some of the math functions have problems handling range or domain errors. Instead of signaling SIGFPE they'll do more creative things like crashing system. Example: log (0.0) o _format() in the math library (actually BSD's _doprnt) will crash if it tries to print an FP value that is an IEEE NaN or INF code. o Other problems. Inconsistent rounding... Floating point testing programs really have a cow. General: o malloc() calls the system memory allocation function for every block that is requeste, no matter how small. This results in slowing down programs that allocate many small chunks (like GCC does). o The I/O functions do not always set errno to the appropriate errno.h error code when there is an error. o There is no startup code for detaching a process from its console. o The Workbench startup code is in an unfinished state. o There is a version of functions.h, the function prototypes for system calls, that defines code that will generate inline calls to the system functions for GCC. The problem is that GCC doesn't understand that there can be side effects caused by these functions, so sometimes it decides to just not call a function. I think I have kludged my way around the problem where it occurs in the library, but I can't be sure. o Signals (signal.h) are limited due to the way AmigaOS that type of thing. The most obvious problem is the control-C keybord interupt. It is polled in some of the I/O functions and if you get stuck in a loop that does not call any of those functions, you can never break the program. (Good luck Marcus) o Some of the more OS specific Unix-like functions are incomplete. You might what to look at the source code before using functions like fstat(). Non-ANSI-ness: o Wide and multi-byte characters are not supported. The functions mblen(), mbstowcs(), wctomb(), and wctombs() are missing. o Locales are not supported. The functions setlocale() and localeconv() and the header file locale.h are missing. All functions that would use locale information always act as though they are in the "C" locale. o Some Standard functions depend on other functions and variables in the library who's names are not "secret", i.e. preceded by a double underscore. The could cause a problem if someone decided to add a function with a name such as `open' or `write'. o The `scan' functions (scanf and relatives) is from BSD. It has been modified to accept more of the Standard conversion specifiers but it still may not conform completely. ======== Ray Burr hoggle!ryb@peora.sdc.ccur.com