Implementing C standard library functions

[NOTNULL]

Hi,
Is it necesasry to implement all the 18 standard C headers, assert, ctype, errno, etc in the OS or just implement the needed header implementation???

Another question, how the library functions written for our OS will be made available to the user program?

I am bit confused about this. Any help greately appreciated.

Thanks,

[AR]

How much you implement is up to you, it only really comes into play when you want to port C programs from other OS' since an incomplete C library may prevent you from porting certain things.

The library functions can be provided either as system calls (not recommended) or as a dynamicly linked library (DLL), or until you get a dynamic linker working you can simply statically link.

[Solar]

The easy answer is, it's your OS, do whatever you like.

For a standards lawyer like me, the answer is paragraph 4.6 of the ISO/IEC standard 9899

The two forms of conforming implementation are hosted and freestanding. A conforming hosted implementation shall accept any strictly conforming program. A conforming freestanding implementation shall accept any strictly conformint program that does not use complex types and in which the use of the features specified in the library clause (clause 7) is confined to the contents of the standard headers <float.h>, <iso646.h>, <limits.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, and <stdint.h>. A conforming implementation may have extensions (including additional library functions), provided they do not alter the behaviour of any strictly conforming program.

You can find the aforementioned freestanding headers in v0.2 of the PDCLib (see my signature). The version is pre-1.0 because 1.0 would be a conforming hosted implementation; you should be safe to use v0.2.

As for "how do I make it available for user-space"... be aware that, at the bottom level, the C whole library boils down to a very few functions actually requiring a system call. You need some function providing the next line of input from some file descriptor as char * - the whole brunt of getchar(), gets(), scanf() etc. etc. is done in user space. E.g. fscanf(), sscanf(), scanf() share lots of code that has nothing to do with the kernel.

The same holds for the other way round: You have printf(), fprintf() etc., but in the end the only system call you need is [tt]write( char const * const outstring, int fd )[/tt].

So, you write one C lib for both kernel and user space; the only difference is that the kernel-space version of the [tt]write()[/tt] system call calls the respective system function directly, while the user-space stub has to do some context-switch magic (like, putting the parameters into registers and triggering an interrupt, or whatever you use to make system calls).

[Colonel Kernel]

A conforming freestanding implementation shall accept any strictly conformint program that does not use complex types

Hmmm... what does it mean by "complex types" here?

[iammisc]

A good way I think to implement things like writing to the console and getting what keys were pressed is to use shared pages. That would require no system calls and you can make sure that no process writes to the keyboard area by making that page read only. Or maybe I am getting this all wrong.

[Simon]

Would that not require the applications to know the address of the shared page at compile time? If you ever changed the address of the shared page and previous applications would cease to function until they were recompiled...

[AR]

How would a program actually clear the buffer as well? There is also the security question in that if the page is mapped in all processes, how do you prevent interception of passwords, it would be extremely easy to install a keylogger even on the guest account...?

[Solar]

Hmmm... what does it mean by "complex types" here?

That was from the C99 standard, which introduced <complex.h> (complex numbers), which usually require library / runtime support.

[iammisc]

About the application being able to find the page, the kernel could push that value onto the process's stack when it first loads up. About the keyloggers, never thought about that, maybe I should give the way I do things in my Os some more though on the security side. To prevent keyloggers using my scheme, the kernel would clear the keyboard page whenever a process switch occured so process A could not read process B's keys because the keyboard buffer is clean.

[AR]

That would also be a problem in that if it flushes the buffer between context switches so that if the process hadn't finished reading it when it was switched then the user's keypresses would be dropped, that also doesn't work for GUIs where the input should only be delivered to the "active" (selected) process, not the currently executing one.