standard library structure

[NickJohnson]

Hi,

Up until now, my C library has contained both my OS' API (which largely deals with filesystem stuff, I/O, and IPC) and the C standard API. Since my API needs things like dynamic memory allocation and math/string functions for its implementation, but higher level C functions like the ones in stdio.h need my API for their implementation, it seems as if they're sort of caught in a dependency cycle, which is why I have them together. I've been able to separate out my driver API into a separate library, but that's pretty much it.

However, I'm planning to write a C++ standard library in the near future, and may write some sort of POSIX wrapper library as well, and it's starting to seem like a good idea to try and separate the C standard functionality from my API more cleanly. This would also make sense if I wanted to re-implement my API in C++ or something. Of course, I then run into the dependency problem. It seems like the simplest solution is to implement clones of string.h, math.h, and stdlib.h in my API, then have the C library be a wrapper over them. This clearly adds some complexity, however, and the whole separation thing makes it so all programs have to link with two libraries in the right order.

I'm wondering what the best way to separate my API and the C library would be, and if doing so would be worth it (i.e. would make things cleaner overall and/or reduce overall complexity.)

Edit: I'm also having similar troubles separating my math library from the C library as well; things like printf("%f") require some logarithm functions, which then means programs would have to always link with libm.

[OSwhatever]

Can't you find a way to make your specific OS functionality to co-exist with standard C/C++ library?

[NickJohnson]

Sure: it already does coexist fine. It just seems like it would be cleaner if it were truly separate. I guess I may be going overboard though...

[gerryg400]

It just gets worse when you start including threads and multi-core into the mix. Many functions need locking and/or TLS info . I'm trying to follow the pthread model. I'm not sure whether stdio should use pthread_mutex_lock, whether to build something simpler on top of pthread_mutex_lock and use that or whether to call my kernel primitive directly. The same questions come up when I consider functions like asctime that need some TLS static data. Right now I'm putting it all in the too hard basket, using newlib plus whatever extras I need to add and concentrating on my kernel.

I think the problem stems from the fact that the c library was not designed as a set of layers or modules but just grew randomly to where it is today.

[rdos]

That would be easy. There should be one include-file for the kernel-interface (mine is rdosdev.h) and one for the user-level interface (mine is rdos.h) that stand alone (does not require header files from C/C++). All the functions in the OS API should start with something unique (all my functions start with Rdos). When I supply the C library, I need certain OS-functions, and those are included from <rdos.h> in the library source. The C library header-files should not require rdos.h to be included, just the normal headers. At least this is the ideal solution. If done in that way, I can see no problem.

[NickJohnson]

The problem is that my API functions are implemented in C, and the API is not just a trivial wrapper over my kernel API (its implementation has about as many SLOC as my kernel.) Because I have a microkernel, the library contains a whole stack of protocols for doing different types of I/O and system operations. It also relies quite heavily on the malloc() heap, and a lot of the API functions require or return heap-allocated pointers.

Basically, my native API library, if separate, would depend on <stdint.h>, <string.h>, most of <stdlib.h>, and parts of <stdio.h>, while most of <stdio.h> and parts of <stdlib.h> (plus anything file-related in a POSIX wrapper) would depend on it. I don't mean that the native API headers would require them, but instead that the code implementing the native API would, which is a linker dependency problem. That's my issue.

I think it's probably best if I just leave things as they are anyway.

[rdos]

When it comes to threads, I have a native thread-creation interface that does not look like POSIX or Windows thread interfaces. I provide the thread-interface in C lib with the native API (or, rather, I export a new thread-interface that has an additional parameter "thread name" because C or POSIX does not have named threads, something that I consider essential).