Creating a C Library: Difference between revisions

Jump to navigation Jump to search

Creating a C Library (view source)

Revision as of 00:41, 12 March 2013

No change in size ,  11 years ago
m
Fixed a few typos.
[unchecked revision][unchecked revision]
VisualWikitext
m (Fix typo)
m (Fixed a few typos.)
Line 1:
This tutorial will discuss implementing your own Standard C Library (libc). While implementing a minimal subset for kernel use is easy, it is considerably more work to implement sufficient functionality to port third party programs. You may wish to save yourself the effort and port an [[C_Library|existing C library]]. Before going ahead, you may wish to create a [[OS_Specific_Toolchain|OS Specific Toolchain]], which will allow us more control of the compiler. Note that this tutorial is somewhat ELF-specific, although the relevatnrelevant details can be adapted to other platforms. This tutorial also contains information on how to adapt your GCC cross-toolchain to your operating system.
 
= Building =
Line 105:
Creating your own C library has a number of advantages. For instance, you can finally add that useful fopen_http that the GNU libc maintainers rejected. You can also add a bunch of new, useful conversion specifiers to your printf. But before you get too carried away, you should spend a few minutes thinking about compatibility. For instance, if you do add your fopen_http and your user-space programs use it, then you just lost portability back to Linux. While you are still bootstrapping your operating system, it is very valuable to be able to run and test your user-space programs from your host operating system. It allows more rapid development and makes sure that your libc functions do the same as the ones on your host system. Rather than adding these new utility functions to libc, it may well be worth adding them to a new separate library, which is portable and works under your operating system and your host operating system.
 
Additionally, you should be very careful about changing semantics of existing libc functions or adding new functions to existing headers (namespace polutionpollution). This may very well confuse third-party programs and cause massive porting problems. Whether you do choose to diverge from the conventional path, you should think twice: Is it really worth it? Can you make a new, nicer function and have the old one call the new one? Could your extension conflict with stuff from BSD, Plan 9, or another libc? Has anyone already decided that a given C interface is bad and made a sane replacement? Choosing to copy the interfaces of implementations can certainly help you port software.
 
Fortunately, you can find plenty of the relevant standards online. For instance, you can look at:
Line 133:
 
= C++ Compatibility =
Traditionally C++ programs can use the C headers, even though such headers are written in C and have C linkage. Unless you specifiyspecify otherwise, GCC will assume that header files found in your system include directory are written in C and have C linkage. This is done by GCC automatically inserting extern "C" { ... } around all included system headers. However, this may lead to strange linking-failures if you try to use C++ headers from the system include directory. The key solution is to make your C headers explicitly compatible with C++ and tell GCC that you understand C++.
 
Telling GCC that your headers understand C++ is as simple as adding the following to your OS-specific gcc/gcc/config/myos.h:
Anonymous user
Retrieved from "https://osdev.wiki/wiki/Special:MobileDiff/4601"
Cookies help us deliver our services. By using our services, you agree to our use of cookies.
More information

Navigation menu