OSDev.org

Two questions to Solar, sorry if these been answered:

1) What's your future release cycle? Any promises on next release or even a snapshot?

2) What are you using as a reference? Do you have a copy on some ISO standard (which?) or some other reference? Or are you just collecting the "known to be standard" functions?

I'm not that excited about the fact that I'm going to need some kind of C library rather soon now (about 3 things to do in kernel and then it's time to start fooling in userspace), and I'm wondering whether there'd be useful libraries to port. PDCLib ofcourse seems pretty ideal so far, which probably isn't surprise.

edit: is it just me, or does it seem like ISO C99 is a monster from the library point of view..

mystran wrote: 1) What's your future release cycle? Any promises on next release or even a snapshot?

PDCLib is rated pre-alpha. As such, think of v0.1 through v0.4 not as "releases", but rather somewhat stable snapshot of the CVS sources. I will make such snapshots whenever I "finished" another header of the library.

At some point, I will switch to making an "alpha" release, i.e. starting to accept bug reports while still reserving the right to make severe structural changes if need be. Then, I'll switch to "beta", which should see only gradual changes, and then finally make a v1.0 release. Right now I am not sure yet whether v1.0 will or will not include floating point stuff (math.h), or whether I'll delay that until v2.0.

I won't make promises, but progress on v0.5 (stdio.h) is good and my motivation is high. However, I got about 1.5 hours / day maximum to work on this, so don't expect any miracles. And no, thank you, but I will continue to work on this alone - it worked out much better this way than the first, colaborative attempt.

2) What are you using as a reference? Do you have a copy on some ISO standard (which?) or some other reference? Or are you just collecting the "known to be standard" functions?

While P.J.Plauger's book "The Standard C Library" is of invaluable help (and includes the relevant parts of the ISO/IEC 9899:1990 standard), my only authoritative reference right now is the ISO/IEC 9899:1999 standards document. Later on, I will add [tt]#ifdef[/tt]'s and stuff that "castrate" the C99 PDCLib to earlier standards.

About the "known to be standard" approach, that's one reason why I don't accept help in this. It's funny how many unknown details lurk in something as simple as strncpy()...

edit: is it just me, or does it seem like ISO C99 is a monster from the library point of view..

Nah, it's just you.

Honestly, C99 didn't add that much to C89. Sure, it added stdint.h and some other stuff, but on the upside it is much clearer on many things (like, the exact meaning of the '%' operator...). All in all, the C standard is quite manageable IMHO, if somewhat obscure in some places. (Did you know that I could make time functions that always return January 1st, 1980, as "the best possible approximation available", without breaking the standard? )

What really makes me shudder is thinking about implementing a C++ library next. ;D

I already knew you are not accepting contributions.

I asked because I wanted to weight whether I should throw together some hack to later replace with PDCLib, or just code a reasonable library myself.

As it is, I think I'm going to go with the latter option, except I think I'm going to forget about ISO C libs for now.

That will allow me to define a small, clean runtime library. But more importantly, not using any of the ISO C API, I won't have to worry about not following the correct semantics, which someone would rely upon.

Better write a totally new API (actually I've already chosen a design to steal), and then wrap ISO C API around that as optional component if later required for porting applications (which is probably is going to happen first when I want things like libpng and freetype ported over).

Solar wrote: It's funny how many unknown details lurk in something as simple as strncpy()...

I hope you read what I posted on the forum on your sourceforge project page (yesterday and today).

Solar wrote:What really makes me shudder is thinking about implementing a C++ library next. ;D

Yeah, that's a lot bigger and more complex.

bluecode wrote:

Solar wrote: It's funny how many unknown details lurk in something as simple as strncpy()...

I hope you read what I posted on the forum on your sourceforge project page (yesterday and today).

Yep. Funny enough that there was another bug in the very function I mentioned here. It's been fixed.

strncpy(), if I'm not mistaken, is broken by design..

like a lot of ISO C library functions really..

Well, depends. They do work as designed, but the API isn't a thing of beauty.

Whoever got it into their heads that strncpy() should fill up the remaining characters with '\0', or that all those string functions return a pointer to the destination buffer (instead of the end-of-string)...

But that's a thing for the individual OS API. I am just out to satisfy the standard, not to make a better one.

Actually, the sane thing for strncpy would be to copy the string, including a null-terminator, but no more than n-1 non-null characters, such that null terminator always fits. Then you could describe it as "copy a string into an array of given length, truncate if destination array is too short" and be done with it. Then it would be safe to recommend it as a safe alternative for strcpy. But instead we have these stupid little special cases which mean it's easier to just write your own str_copy or whatever you wanna call it.

Oh, and the sane thing for strncpy to return would be the number of characters copied. In fact, the sane thing for most string functions to return would the number of characters they operated on, or the index they found something of interest at.

Returning pointers, when the caller already has the pointer makes sense only if your dealing with a system where array indexing is expensive operation, and I don't think you want to have the standard library eat your memory in such an environment anyway.

Solar wrote:I am just out to satisfy the standard, not to make a better one.

I'm not saying I won't do it once PDCLib is done.

Status update. I had to revert a bunch of changes because I got into a dead end, which threw me back in my schedule.

But the fput / fprint functions are working now. Not perfect, not 100% tested, but working, which means I can see my debug output again (instead of writing to memory, calling abort() and hexdumping the corefile, which has been a pain).

Yet to do: adding the wide stream hooks, bugfixes and better tests.

Postponed to v0.6: get / scan functions, floating point support. Yes I know that means only partial stdio.h implementation, but I feel that I should release the print functions ASAP to show the progress made by PDCLib.

I managed to get a snapshot of my local SVN imported to the SourceForge SVN, which means you can now retrieve the latest pre-v0.5 code (including functional printf() functions).

Be warned though that this is a snapshot of unpackaged, unreleased pre-alpha code. It might wake up in the middle of the night and eat your dog. ;D

I'd be more worried about it (when it is initially downloaded) opening a session to my router and overwriting the firmware with its own copy, while modifiying my BIOS settings to boot from the network. Then when I'm in bed the router will use Wake-On-LAN to start my machine up, and send it a bootloader/OS that will format the drives.

[me=Kemp]isn't paranoid...[/me]

Solar, according to C99 don't you define custom additions/modifications to the C library with a _ before its name?
and what exactly is % I have never even used it

% is used as the modulus operator (commonly called mod) and as an indication to printf and suchlike that a placeholder for the string representation of another parameter is about to be defined. eg:
Inserts "1977" into the string instead of %d.

Jordan3 wrote: Solar, according to C99 don't you define custom additions/modifications to the C library with a _ before its name?

Huh? That would really surprise me, where did you get that?

Actually, a standard library header is not allowed to define any identifiers outside the reserved namespace. Note that there's a difference between standard lib (e.g. stdlib.h, which must not define stuff outside the reserved namespace) and system lib (e.g. unistd.h, which must not define stuff inside the reserved namespace).