PDCLib spinoff: kprintf

[Solar]

Since recent activity in the Wiki told me that there is some demand for ready-to-use printing code, I took the printf() implementation from PDCLib and turned it into a self-contained package, implementing:

• kputc
• kputs
• kprintf (including support for everything, except multibyte format strings and floating point output)
• strtol

(The latter is used internally by kprintf(), and I couldn't be bothered yet to edit it away.)

Download of v0.1 is available over at http://pdclib.rootdirectory.de, or here for a direct link. Check out the header file for a more detailed description.

Note that I haven't tested the code, since I don't have any Bochs / Qemu available ATM. It compiles, and it is 99% identical to the code in PDCLib v0.5, so I don't expect much trouble - but you never know.
Instead of delaying the upload until I find the time to set up a Bochs and test it thoroughly, I thought I'd do the Microsoft thing for a change, and throw the code at you lot to figure out the bugs. (Mind you, the printf() itself is sound and well-tested. It's just the kputc() doing all the "navigation" on the 80x25 screen that might have a bug or two, since it's obviously written from-scratch.)

Have fun.

[bluemoon]

It compiles nicely with my kernel CFLAGS and cross compiler.

But passing it to my host compiler reveal a couple of minor issues about :

Code: Select all

kprint.c:325: error: ‘for’ loop initial declaration used outside C99 mode
kprint.c:351: error: ‘for’ loop initial declaration used outside C99 mode

"Older" C don't like declaring variables within for(), ie. for ( size_t i = 0; ... and it's easy to fix by putting size_t i; at top of function.

[Solar]

-std=c99 should've become the default long ago (and actually is alias'ed as such on my system, which is why I didn't have that problem). I refuse to put a crimp in my programming style to satisfy a language spec outdated for a decade and longer.

[bluemoon]

I specify c99 when compiles my kernel too. I don't know why apple insist on default using ancient spec as old as the big bang

[Love4Boobies]

To avoid breaking compatibility with older build systems, obviously. This is also why, in POSIX, the cc utility has been deprecated in favour of c99 which, in turn, is being deprecated in favour of c11. As a side note, C89 was always much more popular than C99 was; however, I expect C11 to gain some popularity mostly because it enables portable multi-threaded applications and because it has better Unicode support.

[Combuster]

C89 was always much more popular than C99 was

History shows that poor code has always been more popular

[qw]

History shows that poor code has always been more popular

Isn't BASIC the most popular programming language of all time?

[Solar]

I just uploaded v0.2 of the package.

Changes:

• added the shift-left to the attribute byte, so text is white-on-black instead of black-on-black.
• removed the compliant but needlessly complex strtol() implementation in favor of much shorter and simpler code. (Downside is you no longer get a compliant strtol() included, you'd have to use the full PDCLib for that. )
• replaced the dependencies to memset() and memmove() with inline code.
• implemented tolower() and memchr() internally instead of relying on compiler support.

Seems to work, too. I hope it's obvious that the code is only supporting the "C" locale and ASCII-7.

[Solar]

v0.3 uploaded.

Changes:

• Support for long long made optional. By default compiling without, i.e. you won't need the long long support functions in GCC.
• Function ksetcolors() added for changing text colors.

[Solar]

I finally got around to installing Bochs and testing this stuff. Apparently, I screwed up somewhere; the "core" of the whole package, kprintf(), isn't properly working.

I'm pulling the plug on this for the time being. I will post again when I'm at v1.0 quality.

[brain]

I should probably put my own kprintf on the wiki. it will fill the gap for now, is reasonably standalone and does most stuff except floating point and multibyte. is there anything I should be aware of before doing that?

[Combuster]

Many people don't like the use of floats in kernel land.

[brain]

Many people don't like the use of floats in kernel land.

Nothing to worry about there then, as I never bothered to implement them

[Solar]

The same limitation (no multibyte, no floats) applies to my implementation.

I would prefer we don't put this code on the wiki, as it is somewhat lengthy. But you could link to your implementation from Printing to Screen.