Changes between Initial Version and Version 1 of InnoTekLibc

Oct 19, 2005, 2:15:13 AM (15 years ago)



  • InnoTekLibc

    v1 v1  
     1InnoTek LIBC or what should probably be called Bird's LIBC by now, is a C runtime library in which the coder is exploring [wiki:TheSingleUnixSpecification The Single Unix Specification] (SUS) and various *BSD, Sun and Linux APIs and constructions used in 'portable' software. While implementing SUS completely and provide a great range of special BSD, Sun and Linux APIs is a kind of ultimate goal, the main focus is on what is '''interesting''' and '''requested''' by porters.
     4== Code Structure ==
     6The LIBC code is separated into two layers, the frontent and the backend.
     8The frontend is all portable code which relies only on the backend and itself. It maintains the errno variable. Standard functions and variables are defined with the name wrapped by the _STD() macro. This macro will prefix the definition with two underscores. An awkscript will scan the sources for _STD macros and generate the libc_alias.a library and a header file with wrapper #defines. libc_alias.a will contain two set of wrappers, one without underscor and one with a single underscore. (BTW when talking about underscores now, we're talking unmangled C names, NOT mangled assembly names.) The header file wrapping calls to the function name without any underscore is included by all the LIBC source files and will make sure that LIBC will use its own code and data and not begin confused by redefinitions done by the user. (The user can redefine any standard C function according to ANSI and this should not affect the CRT, or so I'm told at least.)
     10The backend is interfacing the host OS and will offer a OS neutral interface to the frontend. The backend functions have prefixes like __libc_Back_<grp>[Obj][Action][thing]. Functions with a __libc_back_ prefix are internal to the backend and shall not be called by the frontend.
     12The split between frontend and backend code has not yet been fully completed, and there are still several places where libc calls OS/2 APIs directly. There are also quite a few old style backend functions around. Both these issues will be addressed during the development cycle of LIBC v0.7.