Talk:C Library

types

It sounds to me like the "types" section is totally backwards. Bewing 20:00, 31 August 2012 (CDT)

I changed the name of the section to the more appropriate "Versions," and slightly improved it. Do you have anything more specific in mind? --Love4boobies 09:16, 2 September 2012 (CDT)

The new wording with the extra information is better. However, first, the way osdev uses these libs, the words "hosted" and "freestanding" do not have useful meanings -- they add confusion. The words "kernel" and "userland runtime library" have much clearer meanings, and I think these words need to be added. Second, isn't the "hosted" library the small, incomplete, subset one that is linked into the kernel? The article text has it the other way around. If I have it wrong, that just shows how confusing the terms are. ;) --Bewing 15:24, 4 September 2012 (CDT)

Damn, I knew I couldn't resist doing the occasional edit... so: The "freestanding" part of the library are all those headers that add defines and typedefs, but no code. As such, they require neither a runtime nor a linker. A "hosted" library is the whole of it, i.e. including those headers that require accompaining object code. This has nothing to do with kernel / userland. I would expect virtually every kernel to use (a subset of) the hosted lib. -- Solar 23:57, 4 September 2012 (CDT)

Thanks very much for the clarification. I think we should stick the paragraph you just wrote into the article. I'd say the whole concept of a "freestanding" clib is pretty useless in the context of osdev, then. --Bewing 02:42, 5 September 2012 (CDT)

I was the one who wrote that paragraph. Freestanding implementations are not irrelevant to the world of OS development; they were introduced to the standard for this very purpose (and for embedded programming). The idea is that they don't need to communicate with the underlying environment and can thus always be used for functionality such as variadic functions and macros that indicate arithmetic type ranges; on the other hand, hosted implementations require a lot of rewriting and/or porting---this stuff cannot be used out of the box. E.g., the recommandation generally given to GCC users on this website is that they build a cross-compiler; at that point, they can only use the freestanding library.

However, what Solar says is true---while most of the hosted library has no place in a kernel, some of it makes sense (most notably, string handling). There is an important distinction, though. The main purpose of the standard library is to allow for things to be done portably. As I've mentioned in the paragraph above, the hosted stuff is not portable and since it has to be part of the OS, the advantage of portability, that I've just mentioned, goes away. It thus follows that it doesn't matter whether the OS developer implements standard functions or rolls his/her own incompatible ones that have similar goals. On the other hand, the freestanding stuff should always be used because it's always portable and thus increases the portability of the OS as a whole.

--Love4boobies 11:46, 5 September 2012 (CDT)

I think I disagree about the portability issue. In the end any OS is going to need a userland runtime C library -- as non-portable as that may be. Once a developer has gone to the work of creating that, they do not lose any portability by adding some of it into their kernel, too. Most developers that I know of add a C lib to their kernel in order to get printf functionality, and that's it. It's silly of them, because the variadic interface is a giant bug-filled security hole in your kernel, so you really don't want it there. A kernel does very little string handling. A kernel also does very little math, and therefore arithmetic type ranges are not useful, either. But if you think that freestanding C libs are something that developers should care about and use, then you should add another paragraph to the article explaining why, I think. Because it certainly isn't intuitively obvious to me. --Bewing 16:32, 5 September 2012 (CDT)

I didn't mean that they lose portability because it's in the kernel. I meant that the freestanding library offers portability for free and should thus be used, whereas the hosted library's portability is the developer's responsability (regardless of where it is implemented) and is thus unimportant whether it is used or whether something else is used instead. Trying to come up with a new freestanding library would increase maintainability, whereas coming up with a new hosted library wouldn't. Other clarifications:

• I don't see any reason to have I/O (such as printf or scanf) in the kernel.
• You don't need to be math-intensive to need to know the type ranges (e.g., think of SIZE_MAX).
• By string handling, I was mostly thinking of memset, memcpy and such, which are declared in <string.h>.

--Love4boobies 23:57, 5 September 2012 (CDT)

I think talking about portability is missing the point. The "freestanding" part of the library is something that is solely depending on the implementation of the compiler. GCC, for example, provides its own versions of the freestanding C library headers. -- Solar 04:38, 12 September 2012 (CDT)

It's not missing the point at all. It offers information about the implementation which is used to compile the source for the purpose of portability. In the context of kernel development, code that uses the hosted features is not (as) portable because it requires either porting or implementing said hosted features. (Not sure what GCC has to do with anything.) --Love4boobies 14:31, 13 September 2012 (CDT)

Is Combuster Being Overly Pedantic Again

The whole point of MIT and BSD licenses is that some MIT and Berkeley lawyers worked to create copyright licenses that were as close as humanly legally possible to "public domain" without actually using the words "public domain". You can use, modify, and sell the software to your heart's content, with the only restriction being to maintain the license. I say this is "basically public domain". Combuster says no, this does not meet the precise definition of public domain. Does anyone else wish to comment? Bewing 20:48, 11 September 2012 (CDT)

Then I hope you haven't stubbornly violating license agreements by omitting BSDs demand for attribution, even though in commercial contexts it's sadly standard practice. Yes BSD-style licenses are useful for many things, but contrary to public domain and the later CC0, WTFPL and such you are required to do legal bookkeeping, and from every snippet you grab from the web follows the consequence of needing an extra half a page in your LICENSES document.

Also, the direct consequence of your assumption is that BSD and MIT with all its paid lawyers failed epically at writing the appropriate license texts because the CC0 does things much better than that. Hence, I can't accept the factual accuracy of your statement. - Combuster 07:58, 12 September 2012 (CDT)