mystran wrote:So Solar, how far is your next release?
I guess I'm about two or three weeks of actual work away from releasing v0.5 (stdio), but right now I either don't have the time or I don't have the energy. I'm going to
Breakpoint over the Easter weekend, and hopefully will break my "writer's block" there.
I'm under the impression that stdio needs work, but is it sensible to start porting that to an OS?
It's required for the next step - locales. You wouldn't want to hardcode all available locales into the library, so you load them from file - for that, you need stdio. You need only a few primitives for stdio - read(), write(), open(), close(), that's basically it.
Also how much PDCLib relies on system actually looking like POSIX?
PDCLib relies on a system being able to support a standard C library. I must be able to open a file / stream by name, getting some kind of "file handle" in return, which can then be used to read / write data from / to that file / stream. The details are wrapped in "glue functions", so you can conveniently add any "translation" required between how PDCLib uses the primitive and what your kernel actually provides. Look at
./internals/_PDCLIB_glue.h and
./platform/example/functions/_PDCLIB/.
Are the other alternative libraries? I don't care for full compliance with ANSI or POSIX or anything, but I'd like something like 90% of fully trivial code to be able to compile and run (after I get the necessary system calls up and running.. most kernel infrastructure, except filesystems, is already there).
Currently I'd daresay your best bet is newlib, which does assume POSIX (but you could wrap that yourself, too), and which has a wider scope than just "standard" C.
