Thread: Pjlib?

Originally Posted by Epy

If ANSI C isn't the most portable, then what is?

ISO C. Or maybe POSIX is implied here, which pretty much sticks to ISO.

Of course, if you aren't suppose to use any other headers, I would be very weary of presuming the aim here is portability.

Originally Posted by Epy

If ANSI C isn't the most portable, then what is?

PJLIB?

Their assertion is probably FUD at this point of time, since citing a few cases where a library is not available or not fully available does not substantiate the claim that it "is not the most portable library in the world, nor it's the most ubiquitous". You actually need to provide proof that another library is more portable and cite statistics to show that another library is more ubiquitous.

It is true that the C standard library is not available in the Linux kernel, but in theory one can make it available. Likewise, it might be true that "LIBC will be excluded from compilation of RTOSes to reduce size", but it may also be true that parts of PJLIB may be disabled for the same reason, and that would mean that PJLIB is not necessarily quite as ultraportable as it presents itself.

By the way, Epy, if you are writing on linux, I'm gonna recommend glib (which is supposedly portable elsewhere, but I dunno) for some generic higher functioning. For starters, it is already used in virtually everything on yer desktop already.

Check it out:
GLib Reference Manual
timers, threads, hash tables, btrees, lists, queues, wicked IO stuff, char conversion, unicode, XML, etc etc.

Originally Posted by Epy

Okay, maybe I'm just fail today, but I couldn't readily find anything on the differences between ISO and ANSI C. Care to give me a few examples?

I believe the ISO standard replaced the ANSI standard, more or less, but probably wikipedia can fill you in.

(chanting subliminal voice: glib, glib, glib...)

In that case, you might want to just use pthread for threads -- I am almost certain that "gthreads" are built on top of pthreads, and they work fine together (pthreads and glib).

> For example, LIBC is not available in Linux kernel
It's not the kernels job to provide it. Libc is provided by the compiler, not the environment.

The compiler writer adapts their libc to work with the underlying environment, to provide your super-portable program (which depends only on libc) with the standard API it knows and expects.