Changes between Version 2 and Version 3 of InnoTekLibc

Timestamp:

Oct 19, 2005, 3:20:13 AM (19 years ago)

Author:

bird

Comment:

--

InnoTekLibc

@@ -6 +6 @@
 The LIBC code is separated into two layers, the frontent and the backend. 
 
-The 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.)
+The 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.)
 
 The 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.
+{{{__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.
 
 The 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.