OSDev.org

Solar wrote:

df wrote: i guess you already have one but when i said it was standalone i meant it could be added to pdclib. but it sounds like you have one (im writing mince because i didnt find one in pdc 0.4)

@ Candy:

Why aren't you at Bingen?

uh... oops? I think I forgot to post here that I wasn't going. All together it'd cost me around 125-175 euro to go there, which would be a little bit much for a single weekend... Sorry about not saying so sooner...


About my question you replied to, consider 0xDEADBEEF invalid in the context in which printf is being done. It will segfault (pagefault, whatever) the application (or library) calling it. What does printf have printed then?

If output is to a buffered stream or a string, it will have written abcdefghi to that stream's buffer / the given memory location when segfaulting. The way I picture it ATM, with an unbuffered stream it would have actually written abcdefghi before croaking.

hey Solar,

_very_ nice work I recently threw my old kernel away and started a new one. I'm now using your library also for my kernel and it is really simplifying things very much. I was very surprised that it took around 10mins to implement a memory-management (just write a _PDCLIB_allocpages(...)) on top of my page allocator.

I just wanted to ask if you implement a kind of itoa(...) (I know it's not exactly standard) and when you plan (do you plan? ) to start implementing C++ stuff. Or don't you want to support C++ any more?
Btw. do you need some help? I could do some smaller tasks, if you like.

bluecode wrote: _very_ nice work

Thank you.

I was very surprised that it took around 10mins to implement a memory-management (just write a _PDCLIB_allocpages(...)) on top of my page allocator.

That part will become a bit more complicated once I get around to implement a "real" malloc, but nice to hear nevertheless.

I just wanted to ask if you implement a kind of itoa(...) (I know it's not exactly standard)...

sprintf() is already done (excluding float support) locally, which caters for decimal, octal, and hexadecimal output.

I might think about an extension lib once PDCLib 1.0 is released, but PDCLib itself will be only about the standard, and strictly so.

...and when you plan (do you plan? ) to start implementing C++ stuff. Or don't you want to support C++ any more?

Oh, I want many things. The question is, can I do them in a reasonable time frame and in reasonable quality. The C++ lib is much larger than the C one, incomparably more complex, allows for many more design tradeoffs (-> more compile options), virtually none of the C++ compilers out there is fully standard-compliant yet, and if you have C++ at hand you can implement several parts of the C lib so much more conveniently in C++...

PDCLib will be made so that it can be used as the C subpart of a C++ lib. Beyond that, all bets are off ATM.

Btw. do you need some help? I could do some smaller tasks, if you like.

No, I decided to do this alone, which works better than the coordinated effort I tried at first. Thanks for the offer!

hm, ok

I hope you get where you want with your library and keep up the good work