Where the Printf Rubber Meets the Road (2010)

So for the record, I wrote this four years ago. No idea why this is being linked to from here now.

Let the record show, also, that I in no way stand by this as being a sane approach. I just walked through it, trying to answer the question. I wanted to show the path to syscall and it was way wackier than I thought it would be. That's why it ended up a blog entry.

(Though when my blog went down one day, someone copied the content into the answer:

http://stackoverflow.com/revisions/2444508/3

...and they did so ignoring the license clause difference that my blog is CC-BY-NC-SA instead of CC-BY-SA. There's been a bit of a tussle over that distinction lately, with people selling StackOverflow books:

http://meta.stackoverflow.com/questions/272768/is-this-site-...

...and I'll leave it to those with more interest in the issue to decide if that is worth worrying about, because I don't actually care.)

Anyway, I'm sure the people involved in writing this had their reasons for doing it this way, and it had to do with code legacy and evolution. I don't want anyone to mistake my trace through it as endorsement. It's just what it is.

So what is the reason for all the rest of the indirection and macros? Why __printf and then aliased to printf? Why is outchar a macro instead of being factored into a function? If you asked me to implement printf I wouldn't immediately do all of this - so what would my implementation be missing that makes these necessary?

This is interesting and timely since just recently I attempted to make the same journey in the name of creating a tiny obfuscated C program[0]. However, right at the part where the author says "you might start thinking that you no longer care how printf works" is exactly where I stopped caring.

In the end, I did find out a way to write to stdout without calling putchar or including stdio directly, but there's still some mystery in the call to write:

    // Printing to stdout without stdio or putchar
    // Originally adapted from here:
    // http://stackoverflow.com/a/14296280
    void print_char(char item, int len)
    {
        for (;len; --len)
        {
            write(1, &item, 1);
        }
    }

[0] - https://github.com/lelandbatey/tiny_tree_printer

I had a similar question to this once, and what I mainly found out was that FreeBSD's (and thus OSX's) libc is much, much, more readable than glibc.

The original Stack Overflow question seems to have some fundamentally broken assumptions about implementation in assembly. The design decisions of one random compiler don't determine how all implementations work. And even for that compiler, a lack of inline assembly doesn't mean the standard library can't use assembly; it just has to use separate assembly files. Beyond that, the compiler itself generates machine code, and it can (and does) do so as part of the implementation of varargs.

Regarding the site hosting the article: ugh, it's bad enough to capture the left arrow key and have it go to a previous article, but pay attention to the modifiers to avoid breaking alt-left as a keyboard shortcut for "back". (Browsers shouldn't even allow unprivileged pages to override shortcuts like alt-left.)

In my more nieve days I used to genuinely believe that macros were a cool language feature. Now after spending some time in C/C++ I think macros are the enemy of code readability, and I think this article summarises WHY nicely.

I'm sure there is some political reason why ldbl_strong_alias was used to rename printf to __printf, but frankly I don't really care, there are macros like that all over the C/C++ libraries that make finding the source for anything pure hell.

The only acceptable macro to me now is a block which only runs in the DEBUG build and is skipped over by the compiler in RELEASE.

PS - Yes this is why I don't code in C/C++ very often. I'm currently playing with Go which has no concept of macros.

I messed around with an MSP430 micro controller for a while. There, I didn't want to use a "standard" (Third-party but popular) library. I ended up grabbing and modifying a much more direct version of printf, and I got to the syscall part much quicker. When you only have 256 bytes of RAM and 64 KB ROM, you don't have such luxury. You also dont need to support C++.

I think printf() is one of the more interesting functions in the standard C library to examine, since it is both so often-used and has the very visible effect of producing output. It also shows some of the ways in which data can be interpreted. Variants or limited-functionality versions of it can make good assignments for programming courses.

Printing floating-point numbers is also another topic that is subtly more difficult than it looks at first glance... here's one of the better articles about it: http://www.ampl.com/REFS/rounding.pdf

When I was using actively Turbo/Borland Pascal I always thought that the "Write"/"Writeln" (forgive me, if mispelled) were magic functions :) - since they were taking random amount of arguments, but there was no pre-processor, or "..." as in "C"...

There is a very quick overview of all this here: http://en.wikipedia.org/wiki/Write_(system_call)#Higher_leve...

I think the question comes from a lack of understanding of varargs, not a desire to see a bunch of crappy glue code inside glibc.

And for that type of C newbie who hasn't seen varargs... I'd say the answer is pretty intuitive if you know how to look. First of all the answer is staring at you in the manpage:

   int printf(const char *s, ...);
   int vprintf(const char *s, va_list ap);

OK, so there is the set of ordinary C functions that do it. Look up this va_list thing and an implementation becomes obvious... printf sets up a va_list and calls vprintf... vprintf scans the string for '%' and uses va_arg...

But the important thing is none of this is magic and you can totally guess it just by looking at documentation. I don't think it ever confused me when I learned C. I don't really get why this is so shocking to people who read the manpages.