OSDev.org

Hi there,

sorry for being absent from the board for so long, but I think I needed a break and some new priorities. I doubt I will attend this new board as much as the old ones, but then, the only constant is change, isn't it?

I just released PDCLib v0.4.1, which is a backport of fixes for all known bugs to v0.4 from the development branch. This includes a pure-recursion quicksort algorithm (if you remember the discussion on that one).

v0.5 has been stalled for some time; I think I am ready to push it further. Stay tuned.

Welcome back! We were missing you...

How's it going in your private life?

Good news on PDCLib. I've tried to port it to aos, but I tripped over abort() which doesn't work cleanly. I'm going to go for a second try soon but not right now.

One of the reasons my priorities shifted a bit is that my wife is pregnant again, so I can't complain.

But all in all, I'll probably continue to lie low os-dev-wise, with the exception of PDCLib work continuing.

What was the problem with the abort()?

I use PDCLib for my os and i have the same problem. Not that i expect my programs to terminate yet...

Anyway: compiler dump Basically, whats missing is signal.h

In the meantime, I'll update my sources to incorporate the changes.

Ah, I see... well, that's a result of how I do the development of PDCLib (header by header). It works when you use PDCLib as a partial replacement for an existing library, but of course on a "naked" system the raise( SIGABRT ) from within abort() must fail until there is a working <signal.h> within PDCLib. You will have the same problems with the tolower() called from within functions/_PDCLIB/atomax.c, for example.

In the end, all this will be resolved when the last piece falls into place for the v1.0 release.

Solar wrote:You will have the same problems with the tolower() called from within functions/_PDCLIB/atomax.c, for example.

Good thing ctype isnt a difficult part of the c standard to write
I kindof meant to send this to you until i read you wanted to know the ins and outs of every function in detail.

Oh well, if you want you can take this and skip some boring work. (Or maybe someone else who wants to get that string function to compile)

In the meantime, keep up the good work

Combuster wrote:Good thing ctype isnt a difficult part of the c standard to write

If you assume an ASCII charset and US/UK locale, no. If you want full support for non-ASCII-charsets and international locales, it becomes a bit more complicated.

Your submission is appreciated, nevertheless.

I'm a bit worried it'll be too strictly C compliant not allowing for my OS design (which is of course entirely selfish). I'm going to nearly require unicode for anything and everything except possibly exporting to file and importing from file. All programs should use solely unicode internally etc. That might make quite a bit of libc impossible or clumsy to write/handle. Especially mapping filenames to/from any non-unicode chartype is a nontrivial and nonreversible thing to do, making filenames not match themselves. Just sent out a mail onto the Boost mailing list on the subject of upcasting/downcasting implicitly motivating that both should be disallowed.

Anyway, the abort thing is by it using something that I don't have. Is there a document somewhere that indicates the top-level side of pdclib, IE, what the OS dever has to supply for the default files to just compile and work?

Candy wrote:I'm a bit worried it'll be too strictly C compliant not allowing for my OS design (which is of course entirely selfish).

That's always a problem of course. As the author of PDCLib, I only have two options: Making the lib 100% standard compliant, or making things "better" resulting in a C lib that is only almost compliant and does place restrictions on the underlying OS that are not part of the standard... you know which I'll chose.

I'm going to nearly require unicode for anything and everything except possibly exporting to file and importing from file.

C99 does have support for wide-character and multibyte strings / I/O. printf(), for example, is specified to be multibyte-aware.

All programs should use solely unicode internally etc. That might make quite a bit of libc impossible or clumsy to write/handle.

I don't think so. There will be a couple of "dead" functions in the lib, which would lead to "bad behaviour" if used. (The non-wide/multibyte I/O functions, mainly.) But as long as you have a function for reading /writing a file byte-wise, I don't see a problem ATM.

Especially mapping filenames to/from any non-unicode chartype is a nontrivial and nonreversible thing to do...

What you pass to fopen() for a filename is "implementation-defined", and PDCLib passes it verbatim to whatever file-opening system call your OS provides. Nowhere does it say in the standard that this may not be a multibyte-encoded Unicode string...

Anyway, the abort thing is by it using something that I don't have.

You will have to have some system call to raise signals, and you will have to have a signal to terminate the calling process. Later, I will implement raise() as a wrapper for that system call, and SIGABRT will be defined to whatever integer your system call uses for an equivalent; until then, either you throw abort() out before compiling, or you provide a pseudo-raise() specialized for this case yourself.

Is there a document somewhere that indicates the top-level side of pdclib, IE, what the OS dever has to supply for the default files to just compile and work?

Inspect what is in ./platform/example, and probably tweak it to suit your OS / hardware / tastes.

I'll extend the Makefile at some later point, so that with a source tree like ./platform/MyOS_1.0, ./platform/OtherOS_2.0 etc., all you have to do is a "make MyOS_1.0" to get a library package for your OS. (Right now, the Makefile is aimed at development convenience.) A release version of the PDCLib will also include example configurations for as many platforms as I can get my hands on for testing.

Solar wrote:

Candy wrote:I'm a bit worried it'll be too strictly C compliant not allowing for my OS design (which is of course entirely selfish).

That's always a problem of course. As the author of PDCLib, I only have two options: Making the lib 100% standard compliant, or making things "better" resulting in a C lib that is only almost compliant and does place restrictions on the underlying OS that are not part of the standard... you know which I'll chose.

And you're right about the choice. If you hadn't, I'd be the only one to truly benefit from it, this way the entire world benefits. It benefits everybody a little less than if you'd done it specifically for them, but that's about the best you can do.

I'm going to nearly require unicode for anything and everything except possibly exporting to file and importing from file.

C99 does have support for wide-character and multibyte strings / I/O. printf(), for example, is specified to be multibyte-aware.

Hadn't noticed that, but then again, I haven't researched it and I kind of assumed it wouldn't due to its age. On the other hand, most of it is binary matching and utf-8 has been specifically engineered to allow that on utf8-strings as well for ASCII characters...

All programs should use solely unicode internally etc. That might make quite a bit of libc impossible or clumsy to write/handle.

I don't think so. There will be a couple of "dead" functions in the lib, which would lead to "bad behaviour" if used. (The non-wide/multibyte I/O functions, mainly.) But as long as you have a function for reading /writing a file byte-wise, I don't see a problem ATM.

Well... the one I see mostly confusing is strlen, which would give the correct bytecount but wouldn't need to match the logical character count.

Anyway, the abort thing is by it using something that I don't have.

You will have to have some system call to raise signals, and you will have to have a signal to terminate the calling process. Later, I will implement raise() as a wrapper for that system call, and SIGABRT will be defined to whatever integer your system call uses for an equivalent; until then, either you throw abort() out before compiling, or you provide a pseudo-raise() specialized for this case yourself.

I was trying to get it compiling within 10 minutes and I failed. What can I say - pretty much my own fault. I'll get it in in a while, just not now (have a malloc/free now so my c++ code can compile).

Anyway, you're doing great work on pdclib alone, work that nobody else will need to do again. That alone is something very valuable...If you need anything else, just shout and I'll try

Candy wrote:Well... the one I see mostly confusing is strlen, which would give the correct bytecount but wouldn't need to match the logical character count.

There is <wchar.h> (in C99, not yet in PDCLib), which has mbrlen() for multibyte and wcslen() for wide-char strings. Yes, if your system doesn't support single-byte strings, strlen() would be a "dead" function for most purposes.

I was trying to get it compiling within 10 minutes and I failed. What can I say - pretty much my own fault.

Not really. I should have tested it on a "naked" system, in which case I'd probably have added a stub or removed the function. Won't happen again for v0.5.

If you need anything else, just shout and I'll try

Your copy of Cody&Whaite was already immensely helpful, thanks.

I am necromancing this thread to rub some shame into a festering wound, and then having it cauterized.

Five years of not getting my act together. Five years of whining about <stdio.h>, which isn't really that difficult to implement (if you take your time and think things through, which I didn't, which cost me several extra rounds of re-doing things.)

But hey, what five years they have been. Seeing my first child grow up, and seeing my second child being born. My mother died, quite suddenly and unexpectedly. We renovated and relocated to my childhood home. My daughter is in my old school now, my son in my old kindergarten (actually, the same group and the same kindergarten teacher as myself ). Lots of other things happened, some good, some not so good, and time went by as it does for everyone.

But there was a productivity boost recently, partly thanks to Rink Springer who told me what he was already running successfully on top of PDCLib, and partly to a change of pace at the office that made me rediscover what fun this work can be.

Long story short:

PDCLib v0.5 will be released December 24th, 2010.

There will probably be bugs in there, but it's finally time to package the beast and get it out into the wild.

Just so that you all know.

PS: I expect the next couple of releases - ctype, locale, wchar, wctype, time - to be much faster. Like, by this time next year, I fully expect myself working hard at the math code and towards v1.0.

Good to know that the time until I can do with an unpatched PDClib is becoming shorter

Hi Solar,

Congratulations with all the good news, and my sympathy with all the bad.

Solar wrote:I am necromancing this thread

Good, then this 3 months necroing is not that bad :).

Seeing my first child grow up, and seeing my second child being born. My mother died, quite suddenly and unexpectedly. We renovated and relocated to my childhood home. My daughter is in my old school now, my son in my old kindergarten (actually, the same group and the same kindergarten teacher as myself :D ). Lots of other things happened, some good, some not so good, and time went by as it does for everyone.

Congrats on the kids, condolances on the mom. Otherwise, you seem to have a normal life, which is good :).

PDCLib v0.5 will be released December 24th, 2010.

So, was it? Didn't see any anouncement here. Also can't get much from the project wiki...


JAL