C Library: Difference between revisions

Jump to navigation Jump to search

C Library (view source)

Revision as of 10:38, 23 January 2019

172 bytes removed ,  5 years ago
Add a bit of relativism to the "my C library"; generally update the page to reflect forum sentiments.
[unchecked revision][unchecked revision]
VisualWikitext
mNo edit summary
(Add a bit of relativism to the "my C library"; generally update the page to reflect forum sentiments.)
Line 18:
{{Main|Creating a C Library}}
 
One of the more obvious solutions is to roll your own. You can get seamless integration with your kernel and the rest of the operating system, without portability layers. You also get the ability to progress with function implementations in step with the hardware functionality you add to your kernel. You can effectively write the standard and append custom interfaces to be available to all apps. It is also the one and only option if you happen to be one of the purists out there. It also serves as quite the learning experience.
The best option, in terms of code quality and integration with your operating system, is to write your own C library. You can aim for making a clean and high-quality implementation that follows standards well. It will integrate cleanly with your kernel as no portability layer is needed. You can be secure and robust. You can surpass the limits of what you can do with existing implementations. You can add vendor-extensions that replace bad interfaces and do things better. You can break a lot of code because you followed the standards and applications didn't, then fix the applications as well. It can be better than the competition if you make that your goal.
 
On the flipside, the C library requires a significant amount of time, and using an existing version allows you to spend more effort on your own kernel. In addition, there are a great many caveats hidden in the C language specification, and it is exceedingly easy to write a non-compliant implementation that will later on cause unexpected issues when porting other third part software - or it so happens that your version is actually compliant and whatever you try to port has a hard dependency on glibc quirks.
This is the idealist path and most in the osdev spirit. It has a lot of advantages, but has the steep price of requiring a lot of effort. This may very well be worth it if your goal is to make a ''good'' operating system, not just ''an'' operating system. You don't have to be a libc expert when starting out, but you'll be one when you're done. You might just realize much of the competition out there isn't very good.
 
Here are some existing C libraries for you to pursue:
Creating your own minimal C library is relatively easy. Providing all the primitives needed by real program is a much larger task, but straightforward as you can attempt to cross-compile the software and implement all the missing features causing compilation errors.
 
=== [https://www.gnu.org/software/libc/ Glibc] ===
Line 29:
* Supports almost every architecture
* Generates large programs
* Is not written with anything other than Linux in mind, making it a hard port.
 
=== [https://www.etalabs.net/musl/ Musl] ===
Combuster
1,490

edits

Retrieved from "https://osdev.wiki/wiki/Special:MobileDiff/2964"
Cookies help us deliver our services. By using our services, you agree to our use of cookies.
More information

Navigation menu