getchar() Of The Day

A list of all the canon get characters out there!

[getcharacteroftheday]

The getchar() Of Today Is:

the public domain c library! it's a 100% free implementation with no license restrictions, insofar as that's actually possible

as it targets c99 and higher, it judiciously uses newer standard features like the inline keyword - as you can see, there's a fairly sizable inline function providing most of the behaviour in this getchar implementation

pdclib is far from complete and eagerly accepts contributions if you want to help out!

[getcharacteroftheday]

The getchar() Of Today Is:

mac os x! the first thing you should notice looking at today's code is that it's ridiculously similar to freebsd. the very simple reason for this is that significant components of mac os x, including its libc, were forked directly from freebsd

my favourite part is that the only difference between the two implementations is that apple's fork provides getchar() as a function, while modern freebsd provides getchar() as a macro for getc(). there's not likely to be any performance difference between the two approaches, since apple's implementation of the getchar() function is identical to freebsd's getc() function with stdin hardcoded, but it's fun

[getcharacteroftheday]

The getchar() Of Today Is:

avr libc! this libc is targeted at atmel avr microcontrollers, rather than regular posix systems. it's a reasonably standard implementation, with getchar() as a macro for efficiency

the ATTRIBUTE_CLIB_SECTION seems to be a doxygen thing: it groups all the avr libc stuff under a libc section in the generated documentation. neat!

[getcharacteroftheday]

The getchar() Of Today Is:

freebsd! this code was actually unusually difficult to track down :o the bsd philosophy is to keep the source for the entire operating system in a single repository - since i only needed libc, i skipped everything except lib/libc and then couldn't find stdio.h

anyway i've tracked it down now! freebsd's libc uses macros judiciously - as you can see from the code, the only time single-threaded getchar() so much as calls a function is when the input buffer has been emptied. multi-threaded getchar() needs a few function calls to lock properly however

[getcharacteroftheday]

The getchar() Of Today Is:

knightos! this one is cheating a little bit, because knightos's libc doesn't actually have a getchar() function. knightos is designed to run on texas instruments calculators, and the normal ideas of standard input and output don't make a whole lot of sense on a calculator.

in fact the knightos libc is very unorthodox in general - it's not posix-compliant and many things you'd expect to have available are missing. it's very interesting to look through !

since there's no getchar(), instead we're looking at the code for the read_byte() function, which is knightos's nearest equivalent to the fgetc() function that getchar() usually calls. it takes a stream id, which is akin to a file descriptor under posix, and reads the next char from the stream.

notice that it's implemented almost entirely in assembly language rather than c! this is possible when your libc is guaranteed to run on only a single platform (ti calculators!!)

[getcharacteroftheday]

The getchar() Of Today Is:

glibc! we all knew it was coming. glibc is the standard library used in most major linux distributions and is probably the most commonly deployed libc in the world!

there are two interesting things to notice here: glibc's getchar() is not a macro, and in addition it’s written using the Hecka Weird gnu coding style

seriously, just look at that??? the return type is on a line by itself???? gnu style is so weird

[getcharacteroftheday]

The getchar() Of Today Is:

klibc! it's a tiny libc that only implements a small subset of the standard c library, designed to be used during the bootup of a linux system when the "real" libc is not yet loaded. as you can see it takes a very simplistic approach to implementing getchar() - there's no support for locking at all, so it can't be used in threaded software

however it's great for anything with tight resource constraints! klibc is not only suitable for booting the linux kernel but for various embedded software that needs a small and reliable libc rather than a complete one. very nice!

[getcharacteroftheday]

The getchar() Of Today Is:

bionic! bionic is the libc that android devices rely upon - it's partially written from scratch by google and partially forked from the libc implementations used in various bsds

perhaps the most striking thing about this getchar() implementation is that it's written in c++, not c. bionic's source code is a mixture of the two languages. notice that it uses raii to implementate a threadsafe getc(), rather than wrapping its getc_unlocked() call in a raft of lock macros as most implementations do

[getcharacteroftheday]

The getchar() Of Today Is:

musl! interestingly, musl’s getchar() isn't defined as a macro, nor as an inline function, so its performance is likely to be slightly worse than the other getchar()s we have seen so far

musl is targeted at linux systems rather than embedded devices, so its developers probably found calling a real external getchar() function had a small enough performance hit to be worth the simplified implementation!

[getcharacteroftheday]

The getchar() Of Today Is:

uClibc! again getchar() is a macro, but in uClibc it expands to another macro - __GETC is defined differently depending on whether the platform has thread support

as uClibc is intended for embedded systems it is common not to need threading at all!

[getcharacteroftheday]

The getchar() Of Today Is:

the diet libc! as in most libc implementations, getchar() is simply a macro for fgetc(stdin), which in turn invokes fgetc_unlocked(stdin) in a threadsafe way

notice the use of the __likely and __unlikely macros - these provide branch prediction hints to the compiler. under gcc they expand to the __builtin_expect hint. clever!