OSDev.org

#include <stdio.h>

int main()
{
    char string[] = "test";

    fprintf(stdout, "fprintf stdout %s\n", string);

    fprintf(stderr, "fprintf stderr %s\n", string);

    printf("printf %s\n", string);

    return 0;
}

fprintf stdout test
fprintf stderr printf test

"fprintf stdout test\n" size 0x14
"fprintf stderr %s\n" size 0xf
"printf test\nut test\n" size 0xc

kzinti wrote:Having a different buffer for stdout and stderr seems expected to me.

I run into some weirdness with printf/newlib myself, but it was different than what you see. I worked around the issue by disabling buffering entirely with setbuf(stdout, 0). You might want to give that a try just in case.

kzinti wrote:Having a different buffer for stdout and stderr seems expected to me.

kzinti wrote: multiple processes/threads printing to the same console.

kzinti wrote:The weirdness I saw had to do with multiple processes/threads printing to the same console. It looked as if things were being printed out of order... but of course it was the buffering getting in the way and delaying some output.

Glad you found the problem... These things can get tedious to track down.

kzinti wrote:I am with you... I'm still using newlib for my user space but slowly starting to think about ditching it... It is a nice piece of code to have around so that one can work on more interesting stuff .

Right now I basically have 2 libc (newlib and my own). This is because newlib doesn't have all the pthread functionality I needed to properly support C++ (exceptions and stdlibc++). One step at a time.

xeyes wrote:reasons for not porting a more complete libc, like glibc?

kzinti wrote:glibc is really tired to GNU/Linux

kzinti wrote:In the end, a big chunk of your C library is tied to your OS. So it's not clear that using an existing one is the right thing.

vvaltchev wrote:I used dietlibc at the beginning, but then I switched to libmusl because dietlibc is not maintained.

vvaltchev wrote:Despite I have no multi-thread support, I had to implement full support for set_thread_area() just to make programs to reach main(), no way to fake it.

vvaltchev wrote:it cannot run scripts because libmusl's realpath() implementation requires /proc to exist, and it has no fall-back.

vvaltchev wrote:Anyway, I never considered newlib, simply because I didn't knew it. How it is compared to libmusl? (if anyone has experience with both of them)

nullplan wrote:Aw, poor Fefe. There is some work still being done on it, the most recent commits are from a week ago. And I thank you for that invitation to a refresher on just how bad cvs is. Even finding out that much took a Google search. I still don't know what was changed, and I no longer care to know.

nullplan wrote:Rich Felker was of the opinion that a single-threaded program is merely a multi-threaded program in waiting. Anyway, set_thread_area() on AMD64 should boil down to setting FS.Base. Admittedly, on x86, it is more involved.

nullplan wrote:That was changed recently (committed Nov 30), the current implementation only requires getcwd() and readlink().

nullplan wrote:I have only read the source code. Based on that alone, musl wins by a landslide. Newlib has so many #ifdefs all over the place, and finding what you are looking for takes ages. Whereas musl has straightforward code, is not configurable as you said, and that means it has no bloody #ifdefs if it can possibly help it, which aids readability.

Also the choice of algorithms is better. newlib's sorting algorithm is a standard quicksort, whereas musl is implementing smoothsort. Newlib's malloc() is a bog-standard dlmalloc (requiring sbrk()) whereas musl has its own version. The old one I could read and understand on its own (the new one requires a bit more brain power than I have yet given it). Unfortunately, the old malloc has a tiny little race condition that can cause unconstrained heap growth in multi-threaded applications. But it could be fixed with a big malloc lock.