C: Difference between revisions
m
Reverted edits by Carver (talk) to last revision by Sinetek
| [unchecked revision] | [unchecked revision] |
Glauxosdever (talk | contribs) |
|||
| (17 intermediate revisions by 10 users not shown) | |||
Line 6:
== Libraries ==
{{Main|C Library}}
The C library implements the standard C functions (i.e., the things declared in <stdlib.h>, <math.h>, <stdio.h> etc.) and provides them in binary form suitable for linking with user-space applications.
In addition to standard C functions (as defined in the ISO standard), a C library might (and usually does) implement further functionality, which might or might not be defined by some standard. The standard C library says nothing about networking, for example. For Unix-alike systems, the POSIX standard defines what is expected from a C library; other systems might differ fundamentally.
It should be noted that, in order to implement its functionality, the C library must call kernel functions through system calls. So, for your own OS, you can of course take a ready-made C library and just recompile it for your OS - but that requires that you tell the library how to call your kernel functions, and your kernel to actually provide those functions
It should also be noted that
▲It should also be noted that in most cases you can not use a usermode C library directly in your kernel. Things such as malloc, free, memcpy need to implemented by you before being used. In GCC the "--nobuiltin" flag tells GCC to not use pre-existing builtin functions such as memcpy.
== Things C can't do==
Line 30:
At some point you might want to compile your code with optimizations enabled. This however can lead to unpredictable results if your C code wasn't written properly. You might end up wasting days or weeks trying to find out why your code works flawlessly without optimizations enabled, but as soon as you compile it with optimizations it just doesn't work anymore or even crashes or locks up your OS. Operating systems are usually multi-threaded environments these days, however the optimizer of compilers generally assume that algorithms and memory changes are single-threaded and so only visible to one instance. So if the optimizer determines that your code does something that is redundant and could be optimized away, it might remove code or change it's logic any way it wants. These are legit changes to the code, but in some instance it's not what you want and it will simply break it. To prevent such things from happening, use the [[volatile (keyword)|volatile]] keyword where neccessary.
To fix possible issues due to optimizations performed by processors on runtime (e.g. reordering instructions and memory accesses, caching memory) make sure you use [[atomic operation]]s or [[memory barriers]] where neccessary. This however isn't an optimization specific to the C/C++ language but rather platform and hardware specific.
However, although optimizations increase the severity and apparent number of small bugs in C code, they will never break correct C, assuming the compiler is stable and multi-threading issues are accounted for. Because of this, it is sometimes best to debug with optimizations enabled at all different levels, to make sure that code is absolutely correct. If optimizations are turned off, the bugs are still there, just less noticeable. A release-quality project should work while enabling any combination of optimizations, although it is much harder to make progress while doing so.
== See also ==
* [[Books#C|Learning C]]
* [[C preprocessor]]
* [[C++]]
* [[C MinusMinus|C--]]
* [[Bare Bones]]
[[Category:C]]
[[Category:Languages]]
[[de:C]]
| |||