Where did PDCLIB go? (or: what are the alternatives?)

[Solar]

Aside from some cleanup on web links, Owen has kindly provided me with write access to the PDCLib repository.

I'm in the process of re-familiarizing myself with the project structure, the changes and improvements done by Owen, and the different environment. (I've never worked with either Jam or Mercurial so far.)

My first couple of changes will probably be related to various compiler warnings I am getting (something I was always a bit OCD about), and applying the patch suggested by darkinsanity. (I don't have clang set up ATM, but it seems to make sense and I'll take his word for it.) A good way to get back "the feel", without being disruptive.

[Combuster]

I see I have a lot of my ancient pdclib stubs to replace with proper versions

[Solar]

A quick update.

Owen did significant improvements to the (rather broken) <stdio.h> implementation I delivered in v0.5. This, however, was entwined with adding <threads.h>, multibyte and wide character support, and a couple of supported platforms (splitting the test-only "example" platform into "example", "posix", "win32", and "gandr") -- which I, personally, would not have tackled before <stdio.h> was truly patched and fixed.

I found it difficult to re-orient myself amidst the numerous (helpful) changes Owen did to the codebase, and pretty quickly met the point where I was afraid that further changes would bring more harm than good.

I created a branch at the point where Owen took over in 2012, to "retrace" his steps. There were several ideas behind this:

• Being able to work from a "familiar" codebase;
• working toward an understanding of Owen's changes and additions step-by-step instead of all-at-once;
• not getting tangled between "content" changes and "style" changes;
• verifying that implementations are "correct" and "complete", again step-by-step.

The idea was to reach a point where I could merge "my" branch and "Owen's" branch to, basically, form a release-worthy v0.6 I felt I could competently support and maintain toward later releases.

Seeing how <threads.h> figured prominently in Owen's changesets (and, really, should be considered from the start for the various thread-static things necessary for locale / multibyte / time support), and seeing how <threads.h> included <time.h>, I figured I'd start with creating a <time.h> implementation (which is missing from Owen's branch).

This was a part of the standard I haven't looked at or used before, and a fine bag of laughs it is. Not because of any shortcomings in the standard, but because a) times and dates are a rather non-trivial subject, and b) Linux did a rather poor job abstracting the kernel interface at some point. For <stdio.h>, there are things like open() / close() / read() that work just fine as lib-to-OS plumbing, but in the time area, the borders are entangled indeed.

I think I got it, though.

So, at this point I have time(), clock() and timespec_get(), i.e. the functions to get time information from the kernel, and strftime(), i.e. the function to print time information in custom format.

The next thing is the implementation of time zone and DST support... which is entangled with locales, and stdio... which in my branch is not reliable yet.

Oh joy.

I've just downloaded the tzcode / tzdata packages from http://www.iana.org/time-zones, and will keep hacking this into submission. Stay tuned.

----

Post Scriptum: Of course the "default" branch remains the one to download / use at any point. After all, it is the one with the working <stdio.h>... I will merge any significant improvements of the "retrace" branch back to "default" at regular intervals.

[Solar]

After Rink Springer buggered me about the lack of work done on PDCLib, I took the project under my own wing again.

https://rootdirectory.ddns.net/dokuwiki ... clib:start

There is branches/shepherd, and trunk (my own work, formerly "retrace" branch).

[Solar]

I just realized this thread ranks pretty high in search results on PDCLib, and that link I gave in the last post has gotten stale, so...

The PDCLib website always had, and hopefully always will be, available at http://pdclib.rootdirectory.de.

[AndrewAPrice]

I had success porting Musl to my non-POSIX OS.

There's a syscall function with one giant switch statement, then in each implementation file I print "System call x is unimplemented". (I generated everything up to this stage btw, I didn't do this all by hand!)

Then, as I use the C standard library and try to do something, I emulate what the syscall would do.

[nexos]

Great project, @Solar! I will probably port PDCLib as my libc when I get there to be free from licensing stuff, and because it looks super easy to port.

[ArsenArsen]

There's also https://github.com/managarm/mlibc/ that I contribute to along with other managarm developers. It's MIT licensed so that should prove no issue and I think it'd be interesting to have a non-POSIX OS to check our portability, so to say. We welcome more OSes.